2010/10/5 Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>:
> On 4 October 2010 18:22, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Mon, Oct 4, 2010 at 2:58 AM, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
>>> That requires a new sort for each row. I generated this with a minor
>>> tweak to Pavel's patch to just restart the tuplesort each time (the
>>> "quick-fix" solution). The problem is that performance really sucks,
>>> because it is an O(n^2 log(n)) algorithm.
>> Maybe that's OK. If you're doing repeated median operations on large
>> data sets, perhaps you should expect that to be slow. I bet that
>> people who want to use this as a window function will want one median
>> per group, not n medians per group; and it doesn't seem like a good
>> idea to say - we're not going to let you use this as a window function
>> AT ALL because you might decide to do something that will be really
>> slow. You can always hit ^C if you get tired of waiting. This seems
>> like it's very far from being the most important thing for us to
>> optimize, though of course it's great if we can.
> Well FWIW, here's the quick-fix solution to make this median function
> support window queries.
Is this safe? It seems to me that the tuplesort_end isn't called in
window aggregates at the last of a partition, which results in
forgetting to close temp file if tuplesort is in state of tape.
In response to
pgsql-hackers by date
|Next:||From: Markus Wanner||Date: 2010-10-05 06:57:09|
|Subject: Re: standby registration (was: is sync rep stalled?)|
|Previous:||From: Pavel Stehule||Date: 2010-10-05 05:12:38|
|Subject: Re: Basic JSON support|
pgsql-rrreviewers by date
|Next:||From: Dean Rasheed||Date: 2010-10-05 08:47:52|
|Subject: Re: wip: functions median and percentile|
|Previous:||From: Robert Haas||Date: 2010-10-05 01:49:06|
|Subject: Re: [HACKERS] top-level DML under CTEs|