Re: Patch for removng unused targets

On Tue, Jun 18, 2013 at 5:15 AM, Etsuro Fujita
<fujita.etsuro@lab.ntt.co.jp>wrote:

> Hi Alexander,
>
> I wrote:
> > > > From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> >
> > > > 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?
> >
> > > I've created a patch using this approach.
> >
> > I've rebased the above patch against the latest head.  Could you review
> the
> > patch?  If you have no objection, I'd like to mark the patch "ready for
> > committer".
>
> Sorry, I've had a cleanup of the patch.  Please find attached the patch.
>

 Don't forget about window functions!

test=# EXPLAIN (ANALYZE, VERBOSE) SELECT *, count(*) over (partition by
slow_func(x,y)) FROM test ORDER BY slow_func(x,y) LIMIT
10;                                                                QUERY
PLAN
-------------------------------------------------------------------------------------------------------------------------------------------
Limit  (cost=0.28..3.52 rows=10 width=16) (actual time=20.860..113.764
rows=10 loops=1)
   Output: x, y, (count(*) OVER (?))
   ->  WindowAgg  (cost=0.28..324.27 rows=1000 width=16) (actual
time=20.858..113.747 rows=10 loops=1)
         Output: x, y, count(*) OVER (?)
         ->  Index Scan using test_idx on public.test  (cost=0.28..59.27
rows=1000 width=16) (actual time=10.563..113.530 rows=11 loops=1)
               Output: slow_func(x, y), x, y
 Total runtime: 117.889 ms
(7 rows)

And I don't think it's a good idea to rely on the parse tree to see if we
can remove those unused columns from the target list, because there should
be a lot of optimization that has been done through grouping_planner, and
the parse tree is not necessarily representing the corresponding elements
at this point.  I think it'd be better to see path keys to find out the
list of elements that may be removed, rather than SortClause, which would
be a more generalized approach.

Thanks,
-- 
Hitoshi Harada