On 12/05/2012 04:15 AM, Alexander Korotkov wrote:
On Tue, Dec 4, 2012 at 11:52 PM, Tom Lane
<tgl@sss.pgh.pa.us> wrote:
>> But having said that, I'm wondering (without having read the patch)
>> why you need anything more than the existing "resjunk" field.
> Actually, I don't know all the cases when "resjunk" flag is set. Is it
> reliable to decide target to be used only for "ORDER BY" if it's "resjunk"
> and neither system or used in grouping? If it's so or there are some other
> cases which are easy to determine then I'll remove "resorderbyonly" flag.
resjunk means that the target is not supposed to be output by the query.
Since it's there at all, it's presumably referenced by ORDER BY or GROUP
BY or DISTINCT ON, but the meaning of the flag doesn't depend on that.
What you would need to do is verify that the target is resjunk and not
used in any clause besides ORDER BY. I have not read your patch, but
I rather imagine that what you've got now is that the parser checks this
and sets the new flag for consumption far downstream. Why not just make
the same check in the planner?
A more invasive, but possibly cleaner in the long run, approach is to
strip all resjunk targets from the query's tlist at the start of
planning and only put them back if needed.
BTW, when I looked at this a couple years ago, it seemed like the major
problem was that the planner assumes that all plans for the query should
emit the same tlist, and thus that tlist eval cost isn't a
distinguishing factor. Breaking that assumption seemed to require
rather significant refactoring. I never found the time to try to
actually do it.
May be there is some way to not remove items from tlist, but evade actual calculation?
Did you make any headway on this? Is there work in a state that's likely to be committable for 9.3, or is it perhaps best to defer this to post-9.3 pending further work and review?
https://commitfest.postgresql.org/action/patch_view?id=980-- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services