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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
