More on GROUP BY - Mailing list pgsql-hackers

From jwieck@debis.com (Jan Wieck)
Subject More on GROUP BY
Date
Msg-id m10hG0B-000EBaC@orion.SAPserv.Hamburg.dsh.de
Whole thread Raw
Responses Re: [HACKERS] More on GROUP BY  (Bruce Momjian <maillist@candle.pha.pa.us>)
Re: [HACKERS] More on GROUP BY  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
While  looking  at all these parsetrees I wonder why the hell
    the GroupClause contains a complete copy of the TLE  at  all?
    The  planner  depends on finding a corresponding entry in the
    targetlist which should contain the same expression. At least
    it needs an equal junk TLE. For the query

        SELECT a, b FROM t1 GROUP BY b + 1;

    the  parser  in  fact creates 3 TLE's where the last one is a
    junk result named "resjunk" for the "b +  1"  expression  and
    the GroupClause contains a totally equal TLE.

    Could someone explain that please?

    Wouldn't it be better to have another field (resgroupno e.g.)
    in the resdom  which  the  GroupClause  can  reference?  Then
    changing  the resno's or even replacing the entire expression
    wouldn't hurt because  make_subplanTargetList()  could  match
    them  this  way  and  the expressions for the subplans can be
    pulled out directly from the targetlist. And  it  would  save
    processing  the  group  clauses in the rewriting because they
    cannot contain Var nodes anymore and the entire list  can  be
    ignored.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #

pgsql-hackers by date:

Previous
From: Oleg Bartunov
Date:
Subject: Re: [HACKERS] 6.5 cvs ERROR: copyObject: don't know how to copy 604
Next
From: Andrew Merrill
Date:
Subject: new SCO installation FAQ