On 03/08/2016 07:01 AM, Tom Lane wrote:
> Konstantin Knizhnik <k.knizhnik@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
Attached please find rebased patch.
Unfortunately 3fc6e2d7f5b652b4 still doesn't fix the problem with "lazy" evaluation of target list.
This is why my patch is still useful. But frankly speaking I am not sure that it is best way of fixing this problem,
because it takes in account only one case: sort+limit. May be the same optimization can be useful for other queries.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
