Re: Implementation of GROUPING SETS (T431: Extended grouping capabilities) - Mailing list pgsql-hackers

From Олег Царев
Subject Re: Implementation of GROUPING SETS (T431: Extended grouping capabilities)
Date
Msg-id 54f48e4f0909021419v6e884f03i290402a430be623b@mail.gmail.com
Whole thread Raw
In response to Re: Implementation of GROUPING SETS (T431: Extended grouping capabilities)  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: Implementation of GROUPING SETS (T431: Extended grouping capabilities)
Re: Implementation of GROUPING SETS (T431: Extended grouping capabilities)
List pgsql-hackers
After week-lengthed investigation, now i 'm sure - my level of
qualification not enough for implementation task "GROUPING SETS".
I require documentation about the executor and the planner, i can't
understand scheme of work by source code.
Many code, many cases, but very little information "what is it" and
"how thos work". May be i stupid.
Sorry.

2009/8/14 Pavel Stehule <pavel.stehule@gmail.com>:
> 2009/8/14 Олег Царев <zabivator@gmail.com>:
>> 2009/8/14 Hitoshi Harada <umi.tanuki@gmail.com>:
>>> 2009/8/14 Pavel Stehule <pavel.stehule@gmail.com>:
>>>> 2009/8/13 Hitoshi Harada <umi.tanuki@gmail.com>:
>>>>> 2009/8/14 Pavel Stehule <pavel.stehule@gmail.com>:
>>>>>> I prefered using CTE, because this way was the most short to small
>>>>>> bugs less prototype - with full functionality.
>>>>>
>>>>> You could make it by query rewriting, but as you say the best cleanest
>>>>> way is total refactoring of existing nodeAgg. How easy to implement is
>>>>> not convincing.
>>>>>
>>>>
>>>> I agree. Simply I am not have time and force do it. I would to
>>>> concentrate on finishing some plpgsql issues, and then I have to do
>>>> some other things than PostgreSQL. There are fully functional
>>>> prototype and everybody is welcome to continue in this work.
>>>>
>>>
>>> I see your situation. Actually your prototype is good shape to be
>>> discussed in both ways. But since you've been focusing on this feature
>>> it'd be better if you keep your eyes on this.
>>>
>>> So, Oleg, do you continue on this?
>>>
>>>
>>> Regards,
>>>
>>>
>>> --
>>> Hitoshi Harada
>>>
>>
>>> I'd imagine such like:
>>>
>>> select a, b, count(*) from x group by rollup(a, b);
>>>
>>> PerGroup all = init_agg(), a = init_agg(), ab = init_agg();
>>> while(row = fetch()){
>>>  if(group_is_changed(ab, row)){
>>>    result_ab = finalize_agg(ab);
>>>    ab = init_agg();
>>>  }
>>>  if(group_is_changed(a, row)){
>>>    result_a = finalize_agg(a);
>>>    a = init_agg();
>>>  }
>>>  advance_agg(all, row);
>>>  advance_agg(a, row);
>>>  advance_agg(ab, row);
>>> }
>>> result_all = finalize_agg(all);
>> Fun =) My implementation of rollup in DBMS qd work as your imagine there! =)
>> Also, multiply sort of source we take for CUBE implementation, but
>> this hard for support (sort in group by - it's bloat).
>> As result we have merge implementation of group by, rollup, and window
>> functions with some common code - it's way for grouping of source,
>> Hash implementation group xxx on different hash-tables (with different
>> keys) it's very expensive (require many memory for keys).
>> I hope continue my work, after end of time trouble on work =( (bad
>> TPC-H perfomance)
>>
>
> I thing, so you are afraid too much about memory. Look on current
> postgres. Any hash grouping is faster than sort grouping. Try and see.
> PostgreSQL isn't embeded database. So there are not main goal an using
> less memory. The goal is has features with clean, readable and
> maintainable source code.
>


pgsql-hackers by date:

Previous
From: Dave Page
Date:
Subject: Re: community decision-making & 8.5
Next
From: Tom Lane
Date:
Subject: Re: community decision-making & 8.5