More on GROUP BY

Поиск
Список
Период
Сортировка
От jwieck@debis.com (Jan Wieck)
Тема More on GROUP BY
Дата
Msg-id m10hG0B-000EBaC@orion.SAPserv.Hamburg.dsh.de
обсуждение исходный текст
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Oleg Bartunov
Дата:
Сообщение: Re: [HACKERS] 6.5 cvs ERROR: copyObject: don't know how to copy 604
Следующее
От: Andrew Merrill
Дата:
Сообщение: new SCO installation FAQ