Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace
Date
Msg-id 11879.948776470@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace  (Philip Warner <pjw@rhyme.com.au>)
Responses Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace
List pgsql-hackers
Philip Warner <pjw@rhyme.com.au> writes:
> Just a thought, but would I be right in saying that this could be easily
> done with the addition of a new aggregate function 'FIRST', which simply
> returns the first value sent to it? Since the aggregates operate a row at
> a time, you are guaranteed a consistent set of values, I think.

No, because the system doesn't guarantee to deliver tuples to the
aggregate in any particular order.  The physical order of tuples
on the disk will depend on the order in which they were last updated
(plus random perturbations introduced by VACUUM); and the order in
which they are processed by a query will depend on the query plan
chosen by the planner (sequential scan vs. indexscan, etc).
SQL in general doesn't believe that tuple ordering has any semantic
significance --- you can ask for ORDER BY, but that's only honored
at the end stage of SELECT result delivery, not necessarily anywhere
in the bowels of a query.

Also, if you are going to use an aggregate, ISTM you might as well
use one like MIN() or MAX() and get a fully predictable result.
I suppose a FIRST() aggregate would save a few cycles by not running
comparisons, but I bet it'd be tough to notice any difference.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: [HACKERS] fatal copy in/out error (6.5.3)
Next
From: Don Baccus
Date:
Subject: Re: [HACKERS] Happy column dropping