Re: Aggregate ORDER BY patch

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: Aggregate ORDER BY patch
Дата
Msg-id 87eimxwglm.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на Re: Aggregate ORDER BY patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Aggregate ORDER BY patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>> Updated version of the aggregate order by patch.
Tom> I'm starting to look at this now.  I find it rather bizarre toTom> merge both the actual arguments of an aggregate
andthe optionalTom> ORDER BY expressions into a single targetlist.  It doesn't seemTom> like that would be an
especiallyconvenient representation toTom> work with,
 

It's extremely convenient, since you need the arguments and the
ordering expressions together in a slot in order to feed them to
tuplesort (in the general case where there is more than one
expression); you need a tupledesc to pass to tuplesort; and there are
existing functions to construct all of these things from the tlist.
Also, you want to merge the argument expressions and ordering
expressions where possible, and this is exactly what the existing
transformSortClause stuff expects.
Tom> and I would also expect there to be a nonzero performance hitTom> from the extra TargetEntry expression nodes,
evenwhen theTom> feature is not in use.
 

I tested for that and couldn't reliably detect any (certainly <2%
on count(i) on generated data, and under the circumstances I was
testing that's not necessarily outside the error margin).

-- 
Andrew (irc:RhodiumToad)


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Python 3.1 support
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Streaming replication and non-blocking I/O