Re: [HACKERS] More on GROUP BY
От | jwieck@debis.com (Jan Wieck) |
---|---|
Тема | Re: [HACKERS] More on GROUP BY |
Дата | |
Msg-id | m10hWwm-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
(jwieck@debis.com (Jan Wieck))
|
Список | pgsql-hackers |
Bruce Momjian wrote: > The real problem is that it is hard to keep all these items synchronized > as they pass around through the stages. I looked at the aggregates, and > it looks like that has a separate copy too, so it may not be that bad. > We may just be missing a pass that makes appropriate changes in GROUP > clauses, but I am not sure. Exactly the probability of missing some changes somewhere is why I would like to get rid of the field entry in GroupClause. Having to keep duplicate items synced isn't the spirit of a relational database. It's like using triggers to keep two tables in sync where a simple reference and a view would do a better job. > > I think it's true that using a TLE for each grouplist item is a waste of > > space, and that representing the grouplist as simply a list of expr's > > would be good enough. But pulling out the TLE decoration seems like > > it's not an appropriate use of time at this stage of the release cycle. > > I'd say hold off till after 6.5, then fold it in with the parsetree > > redesign that you keep muttering we need (I agree!). > > Basically, it is my fault that I am bringing up the issue so late. If I > had done the Open Items list earlier, we would not be so close to the > final. And my fault to spend too much time playing around with a raytracer. Developers should develop, publishers should publish. > > Jan is currently researching it, and we have the regression tests and > three weeks. He usually does a fine job of fixing things. Thanks for the compliment :-) > Jan, find > out what you think is required to get this working, and if it is not too > bad, maybe we should go ahead. > > What does the Aggreg do? Does it has similar duplication? Not AFAICS. Aggregates can only appear in the targetlist by default. and the nodes below them are the expression to aggregate over. If an aggregate should appear in the WHERE clause it must be placed into a proper subselect (the rule system already tries to do so if an aggregate column is used in the WHERE of a view select, but fails sometimes). I'll go ahead now in little steps. 1. Get rid of the TLE copy in GroupClause. 2. Move the targetlist expansion into the rule system. 3. Rewrite the subquery creation for aggregates in the WHERE clause to take view grouping into account. 4. Allow qualifications against aggregates to be given as "AggCol op Value" by swapping the expression and using the negator operator (if one exists). As you said, we have three weeks. Let's see what one Wieck can do in this time :-) 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 по дате отправления:
Следующее
От: Thomas ReinkeДата:
Сообщение: Re: [GENERAL] backend dies suddenly after a lot of error messages