From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: wip: functions median and percentile |
Date: | 2010-10-11 15:44:08 |
Message-ID: | 24543.1286811848@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-rrreviewers |
Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> On 11 October 2010 15:03, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Reflecting on it, I think it'd be best to allow an agg to
>> provide an estimation function that'd be told the input data type and
>> expected number of rows --- even on a per-aggregate basis, a constant
>> estimate just isn't good enough.
> How good will that estimate of the number of rows be though?
It can't possibly be any worse than a hard-wired constant ;-)
> If they're coming from a SRF it could be a huge under-estimate, and you'd
> still risk eating all the memory, if you allowed a hash aggregate.
If, for a particular aggregate, you're too chicken to ever allow hash
aggregation, you could just return a very large number from the
estimation hook function. I doubt that's a very useful behavior in the
majority of cases though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-10-11 16:03:19 | Re: On the usefulness of hint bits |
Previous Message | Leonardo Francalanci | 2010-10-11 15:30:54 | Re: On the usefulness of hint bits |
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2010-10-11 17:34:51 | Re: wip: functions median and percentile |
Previous Message | Dean Rasheed | 2010-10-11 15:30:46 | Re: wip: functions median and percentile |