Konstantin Knizhnik <k.knizh...@postgrespro.ru> writes: > Attached please find improved version of the optimizer patch for LIMIT clause.
This patch isn't anywhere close to working after 3fc6e2d7f5b652b4. (TBH, the reason I was negative about this upthread is that I had that one in the oven and knew it would conflict spectacularly.) I encourage you to think about how an optimization of this sort could be made to work in a non-kluge fashion in the new code structure. I've not spent a lot of time on this, but I think maybe what would make sense is to consider both the case where function calculations are postponed to after ORDER BY and the case where they aren't, and generate Paths for both. Neither approach is a slam-dunk win. For example, suppose that one of the tlist columns is md5(wide_column) --- it will likely not be preferable to pass the wide column data through the sort step rather than reducing it to a hash first. This would require some work in grouping_planner to track two possible pathtargets, and work in create_ordered_paths to generate paths for both possibilities. A possible objection is that this would add planning work even when no real benefit is possible; so maybe we should only consider the new way if the tlist has significant eval cost? Not sure about that. There is also something to be said for the idea that we should try to guarantee consistent semantics when the tlist contains volatile functions. For now, I've set this commitfest entry to Waiting on Author. There's still time to consider a rewrite in this 'fest, if you can get it done in a week or two. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers