Skip site navigation (1) Skip section navigation (2)

Re: wip: functions median and percentile

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Stark <gsstark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Hitoshi Harada <umi(dot)tanuki(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-14 00:54:42
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-rrreviewers
On Wed, Oct 13, 2010 at 6:56 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> 2010/10/13 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
>> 2010/10/13 Peter Eisentraut <peter_e(at)gmx(dot)net>:
>>> On mån, 2010-10-11 at 20:46 +0200, Pavel Stehule wrote:
>>>> The problem is in interface. The original patch did it, but I removed
>>>> it. We cannot to unsure immutability of some parameters now.
>>> How about you store the "immutable" parameter in the transition state
>>> and error out if it changes between calls?
>> yes, it's possibility. Now I looking there and I see the as more
>> important problem the conformance with ANSI SQL. see my last post.
>> There can be a kind of aggregate functions based on tuplesort.
> more - all these functions needs to solve same problem with planner
> and hash agg. So maybe is time to add a flag ISTUPLESORTED to pg_proc
> and add solve these functions together.

I think that the design of this patch is still sufficiently up in the
air that it is not going to be practical to get it committed during
the current CommitFest, which is nearly over, so I am going to mark it
as Returned with Feedback.  I suggest that we continue discussing it,
however, so that we can get things squared away for the next
CommitFest.  It seems that the fundamental question here is whether
median is an instance of some more general problem, or whether it's a
special case; and more importantly, if it is an instance of a more
general problem, what is the shape of that general problem?

Or to put it more bluntly - what is the "problem with planner and hash
agg" that all of these functions need to solve?  And why does it need
a flag in pg_proc?  Why can't't we leave it to the individual
functions to perform a sort of one is needed?

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2010-10-14 01:01:06
Subject: Re: [JDBC] Support for JDBC setQueryTimeout, et al.
Previous:From: Christian UllrichDate: 2010-10-14 00:30:43
Subject: Re: [GENERAL] Text search parser's treatment of URLs and emails

pgsql-rrreviewers by date

Next:From: Greg StarkDate: 2010-10-14 02:37:37
Subject: Re: wip: functions median and percentile
Previous:From: Pavel StehuleDate: 2010-10-13 10:56:06
Subject: Re: wip: functions median and percentile

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group