El 11/11/18 a las 07:38, Tom Lane escribió:
I think you have the right basic idea, but we don't have to completely lobotomize the bitmap-and search logic in order to cope with this. This code is only trying to figure out which paths are potentially redundant, so for a path with too many quals, we can just deem it not-redundant, as attached.
Thanks for the patch, looks good to me.
A different line of thought is that using equal() to compare quals here is likely overkill: plain old pointer equality ought to be enough, since what we are looking for is different indexpaths derived from the same members of the relation's baserestrictinfo list.
I didn't realize that we could just hash the pointers here, this simplifies things. But indeed it makes sense to just use a simpler logic for such extreme queries, because we won't have a good plan anyway.
Another thought is that maybe we need a CHECK_FOR_INTERRUPTS call somewhere in here; but I'm not sure where would be a good place. I'm not excited about sticking one into classify_index_clause_usage, but adding one up at the per-path loops would not help for this case.
We added some interrupt checks as a quick fix for the client. In the long run, I think we don't have to add them, because normally, planning a query is relatively fast, and unexpected slowdowns like this one can still happen in places where we don't process interrupts.
-- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
