Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace
Дата
Msg-id 11879.948776470@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace  (Philip Warner <pjw@rhyme.com.au>)
Ответы Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace  (Don Baccus <dhogaza@pacifier.com>)
Список 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 по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: [HACKERS] fatal copy in/out error (6.5.3)
Следующее
От: Don Baccus
Дата:
Сообщение: Re: [HACKERS] Happy column dropping