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
|
Список | 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 по дате отправления: