| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Greg Stark <gsstark(at)mit(dot)edu> | 
| Cc: | pgsql-hackers(at)postgresql(dot)org, Chris Spotts <rfusca(at)gmail(dot)com> | 
| Subject: | Re: Aggregate-function space leakage | 
| Date: | 2009-07-23 18:36:38 | 
| Message-ID: | 23114.1248374198@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Greg Stark <gsstark(at)mit(dot)edu> writes:
> Rereading your diagnosis of Merlin Moncure's original problem I'm a
> bit puzzled. Why do we have to rerun the final function when we rescan
> the hash table? Surely the logical thing to do is to store the final
> value in the hash table with some flag saying that value has been
> finalized rather than to reexecute the final function every time it's
> rescanned.
In the normal case where we're not going to do a rescan, this would very
likely make things slower because we'd have to make a never-used extra
copy of the function's output.  It might be worth doing if we knew we
were likely to get rescanned; but I'm not eager to have two
significantly different operational modes for that.  nodeAgg is
complicated enough already...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2009-07-23 18:42:56 | Re: join regression failure on cygwin | 
| Previous Message | Tom Lane | 2009-07-23 18:32:29 | Re: Aggregate-function space leakage |