We have a zabbix instance on which we make an intensive use of discovery and the server was often clogged,
lots of messages:
" cannot process discovery rule "xxxxx": another value is being processed"
There was a request which was performing very badly:
select ia.itemappid,ia.itemid,ia.applicationid
from items_applications ia,item_discovery id1,item_discovery id2
where id1.itemid=ia.itemid and id1.parent_itemid=id2.itemid and id2.parent_itemid=xxxxx
We replaced the item_discovery_2 index with a more complete one:
CREATE UNIQUE INDEX item_discovery_3
ON public.item_discovery
USING btree
(parent_itemid,itemid );
DROP INDEX public.item_discovery_2 ;
VACUUM ANALYZE FULL public.item_discovery ;
The request now executes in a few milliseconds with more than 10k entries in public.item_discovery .
Maybe this could help someone with the same issues as us, and anyway the supplementary column allows index-only scans in postgres and should not impact significantly the I/O writes on the table.
lots of messages:
" cannot process discovery rule "xxxxx": another value is being processed"
There was a request which was performing very badly:
select ia.itemappid,ia.itemid,ia.applicationid
from items_applications ia,item_discovery id1,item_discovery id2
where id1.itemid=ia.itemid and id1.parent_itemid=id2.itemid and id2.parent_itemid=xxxxx
We replaced the item_discovery_2 index with a more complete one:
CREATE UNIQUE INDEX item_discovery_3
ON public.item_discovery
USING btree
(parent_itemid,itemid );
DROP INDEX public.item_discovery_2 ;
VACUUM ANALYZE FULL public.item_discovery ;
The request now executes in a few milliseconds with more than 10k entries in public.item_discovery .
Maybe this could help someone with the same issues as us, and anyway the supplementary column allows index-only scans in postgres and should not impact significantly the I/O writes on the table.