proposal: tuplestore, tuplesort aggregate functions

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: proposal: tuplestore, tuplesort aggregate functions
Date: 2010-08-18 12:08:43
Message-ID: AANLkTik63xkHRgmr45zPDk755Z=qFMhXusPvtxeoJ2Zt@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello

I still thinking about a "median" type functions. My idea is to
introduce a new syntax for stype definition - like

stype = type, or
stype = ARRAY OF type [ ORDER [ DESC | ASC ]], or
stype = TUPLESTORE OF type, or
stype = TUPLESORT OF type [ DESC | ASC ]

when stype is ARRAY of then final and transistent functions can be a
PL functions. When stype isn't scalar, then sfunc can be undefined (it
use a buildin functions). Then we can implement a aggregate only with
final functions.

so median function can be defined:

CREATE FUNCTION num_median_final(internal) RETURNS numeric AS ...
CREATE AGGREGATE median(numeric) (stype = TUPLESORT OF numeric,
finalfunc = num_median_final);

This feature has impact primary on agg executor, and can be relative
simple - no planner changes (or not big), minimal parser changes.

Main reason for this feature is possible access to tuplesort and
tuplesort. I hope, so this can solve a problems with computing a
median and similar functions on very large datasets.

comments?

regards

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2010-08-18 12:20:15 pgsql: Coerce 'unknown' type parameters to the right type in the
Previous Message Robert Haas 2010-08-18 11:40:04 Re: security label support, part.2