> TBH, I see no convincing explanation in that article of why 1300 partial > indexes are a good idea.
I don't like it much either. I've been trying to eliminate most of the need for the partial indexes, but this is the current state of things. > *At best*, you're doing substantial work in the > planner to avoid the first tree descent step or two in a single > non-partial index. While the specific example I gave in the post could be replaced with a non-partial index, most of the partial indexes contain predicates that are not straightforward to index with non-partial indexes. About 85% of the partial indexes contain a regular expression in them for CSS selector matching. I've tried using a trigram GIN index, but it wound up not working too well due to the data being highly redundant (almost every CSS hierarchy contains 'div' in it). Additionally, most of the predicates for partial indexes are extremely specific making the partial indexes very small. The sum total size of all of the partial indexes is still much smaller than if we were to index every necessary field with regular indexes. Thanks, Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
