From: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Greg Stark <stark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Odd out of memory problem. |
Date: | 2012-03-31 05:59:44 |
Message-ID: | CAP7Qgm=Uoy64_jnmiYhs+2NuOwnekpYjCogy0BzKgqgnNn82Jg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 29, 2012 at 7:38 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On tis, 2012-03-27 at 00:53 +0100, Greg Stark wrote:
>> Hm. So my original plan was dependent on adding the state-merge
>> function we've talked about in the past. Not all aggregate functions
>> necessarily can support such a function but I think all or nearly all
>> the builtin aggregates can. Certainly min,max, count, sum, avg,
>> stddev, array_agg can which are most of what people do. That would be
>> a function which can take two state variables and produce a new state
>> variable.
>
> This information could also be useful to have in PL/Proxy (or similar
> FDWs) to be able to integrate aggregate computation into the language.
> Currently, you always have to do the state merging yourself.
>
I don't know exactly how PL/Proxy or pgpool accomplish the multi-phase
aggregate, but in theory the proposal above is state-merge function,
so it doesn't apply to general aggregate results that passed through
the final function. Of course some functions that don't have final
functions are ok to call state-merge function on the results.
Thanks,
--
Hitoshi Harada
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2012-03-31 08:28:38 | Tab completion of double quoted identifiers broken |
Previous Message | Robert Haas | 2012-03-31 03:41:39 | measuring lwlock-related latency spikes |