johno wrote
> The question is... why is the query planner unable to make this
> optimization for the slow query? What am I missing?
Short answer - your first and last queries are not relationally equivalent
and the optimizer cannot change the behavior of the query which it is
optimizing. i.e. you did not make an optimization but rather choose to
reformulate the question so that it could be answered more easily while
still providing an acceptable answer.
The question main question is better phrased as:
Give me 100 updated at t(0) but only that are subsequent to a given ID. If
there are less than 100 such records give me enough additional rows having t
> t(0) so that the total number of rows returned is equal to 100.
Both queries give the same answer but only due to the final LIMIT 100. They
arrive there in different ways which necessitates generating different
plans. At a basic level it is unable to push down LIMIT into a WHERE clause
and it cannot add additional sub-queries that do not exist in the original
plan - which includes adding a UNION node.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Slow-query-with-indexed-ORDER-BY-and-LIMIT-when-using-OR-d-conditions-tp5812282p5812285.html
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.
