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
Re: [HACKERS] More on GROUP BY |
Список | 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 по дате отправления: