Re: Odd subselect in target list behavior WRT aggregates
От | Mike Mascari |
---|---|
Тема | Re: Odd subselect in target list behavior WRT aggregates |
Дата | |
Msg-id | 3E31899D.1000603@mascari.com обсуждение исходный текст |
Ответ на | Re: Odd subselect in target list behavior WRT aggregates (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > "Mike Mascari" <mascarm@mascari.com> writes: > >>Hello. I have some code which generates subselects in the target >>list of a query and then aggregates the results. The code allows >>the user to determine the attributes of the aggregation. If the >>user chooses to aggregate on the same value twice, I get the >>"Sub-SELECT" error. If the user chooses a different second >>attribute of aggregation, no error occurs. Is that correct >>behavior? > > > This seems to be fixed as of 7.3, though I do not recall a previous > bug report like it. Thanks, Tom. I should have tried the current version before posting. > > However, I wonder why you are doing it like that, and not with a join: > > SELECT SUM(p.dstqty) as agg, > date_trunc('hour', sales.active) as field1, > date_trunc('day', sales.active) as field2 > FROM purchases p, sales > WHERE p.purchase = sales.purchase > AND ... > GROUP BY 2,3; > > The multiple-sub-select approach will require a separate probe into > "sales" to retrieve each of the fields; there's no optimization across > different subselects. Normally, the grouping is done on two or more distantly related pieces of data: "How many widgets were sold by John on Mondays?" "What is the most popular hour for sales by quarter?" etc. So the nature of the data is such that to dynamically generate the proper joins in the FROM/WHERE clause was too complex (for me). :-) Thanks again, Mike Mascari mascarm@mascari.com
В списке pgsql-hackers по дате отправления: