Hi List.
I have a form with filter inputs and this form produces SQL like:
select * from t where id in( select id from t join filter1... join filter2... )
Usually the query plan has the "in" subquery at the beginning and the result table at the end.
The subquery plan rows is usually 1, actual rows is usually 8. The result table is usually joined using the index
scan.
When using more filters than usual at once, the query plan turns upside down and the result table is fully scanned
withoutany filter and before all joins despite its plan rows =200,000 and the subquery plan rows is still =1.
I'm trying to understand why. Is there some complexity limit after which the planner starts acting dumb?
Also, I tried to force the desired plan (only to see if its cost is really higher than the cost of the default plan).
However,pg_hint_plan just prints "not used hints" for some of my NestLoop() hints while accepting the others. And set
enable_mergejoin= OFF and such only change the join method, but don't fix the order.
