Re: Patch for removng unused targets

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