On 12/05/2012 04:15 AM, Alexander Korotkov wrote: > On Tue, Dec 4, 2012 at 11:52 PM, Tom Lane <t...@sss.pgh.pa.us > <mailto:t...@sss.pgh.pa.us>> wrote: > > Alexander Korotkov <aekorot...@gmail.com > <mailto:aekorot...@gmail.com>> writes: > > On Mon, Dec 3, 2012 at 8:31 PM, Tom Lane <t...@sss.pgh.pa.us > <mailto:t...@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
