Atri Sharma <atri.j...@gmail.com> writes: > I understand the reasons for executing SELECT before the sort. But, > couldnt we get the planner to see the LIMIT part and push the sort > node above the select node for this specific case?
[ Shrug... ] I don't see the point. If the OP actually cares about the speed of this query, he's going to want to avoid the sort step too, which is what makes the index a good idea. More generally, this is not a transformation we could apply unconditionally --- at the very least it'd need to be avoided when volatile functions are involved, and I don't think it's invariably a win from a cost standpoint even if there aren't semantic blockers. But right now the planner has no real ability to reason about placement of SELECT-list evaluation: it's done in a fixed spot in any particular plan structure. I don't think it's practical to add such considerations to the rat's nest that is grouping_planner and friends. I have ambitions to replace all that with a Path-generation-and-comparison approach, and the Paths used for this would need to carry some indication of which expressions would be evaluated where. So maybe once that's done we could think about whether this is worth doing. I remain dubious though. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers