> 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
