From: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Fetter <david(at)fetter(dot)org>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: wip: functions median and percentile |
Date: | 2010-10-01 15:35:03 |
Message-ID: | AANLkTimPZg_yd+XRuX84KsB_dzDURX=7F1k7HP+m3qsk@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-rrreviewers |
2010/10/2 Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> writes:
>>> Another suggestion?
>>
>> The implementation I would've expected to see is to do the sort
>> and then have two code paths for retrieving the median, depending
>> on whether the sort result is all in memory or not.
>
> Would it make sense to accumulate value/count pairs in a hash table,
Maybe, but it still has memory problem if the values vary, right? And
I'm not familiar with the algorithm of median other than what the
current patch does, so I'm not sure if hash table solution can be made
easily.
Regards,
--
Hitoshi Harada
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2010-10-01 15:38:21 | Re: patch: SQL/MED(FDW) DDL |
Previous Message | Hitoshi Harada | 2010-10-01 15:32:03 | Re: wip: functions median and percentile |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2010-10-01 17:37:03 | Re: wip: functions median and percentile |
Previous Message | Hitoshi Harada | 2010-10-01 15:32:03 | Re: wip: functions median and percentile |