From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> |
Cc: | Олег Царев <zabivator(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
Subject: | Re: Implementation of GROUPING SETS (T431: Extended grouping capabilities) |
Date: | 2009-05-12 06:21:55 |
Message-ID: | 162867790905112321q1dabd234scc428f8a4a589d08@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2009/5/12 Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>:
> 2009/5/11 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
>> I am thinking so Grouping Sets based on CTE should be more commitable
>> code. It doesn't mean so your ideas are wrong, but these
>> optimalization should to work on CTE too.
>>
>> select * from table group by rollup(a,b,c)
>>
>> have to have generate same plan as
>>
>> with q as (select * from table)
>> select * from q group by a,b,c
>> union all
>> select * from q group by a,b
>> union all
>> select * from q group by a
>> union all
>> select * from q;
>>
>> and CTE is more general then Grouping Sets, so it is better do
>> optimalization over CTE than Grouping Sets.
>
> If you need to buffer tuples from the outer plan and to rescan it
> multiple times, tuplestore seems more appropriate solution than using
> CTE node, from semantic point of view. During CTE and window functions
> development, tuplestore now has that kind of capability and CTE node
> is only a wrapper of tuplestore.
>
> Moreover, I guess you don't even need to buffer tuples to aggregate by
> different keys. What you have to do is only to prepare more than one
> hash tables (, or set up sort order if the plan detects hash table is
> too large to fit in the memory), and one time seq scan will do. The
> trans values are only to be stored in the memory, not the outer plan's
> results. It will win greately in performance.
it was my first solution. But I would to prepare one non hash method.
But now I thinking about some special executor node, that fill all
necessary hash parallel. It's special variant of hash agreggate.
regards
Pavel Stehule
>
>
> Regards,
>
> --
> Hitoshi Harada
>
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2009-05-12 11:15:05 | Re: New trigger option of pg_standby |
Previous Message | Khee Chin | 2009-05-12 05:36:20 | Re: Show method of index |