Re: Inlining comparators as a performance optimisation

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Inlining comparators as a performance optimisation
Дата
Msg-id CA+TgmoZiX2ErOWmGpHMHaMt8qsMSsyxB1_ujei_G380c+BnWEQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Inlining comparators as a performance optimisation  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Inlining comparators as a performance optimisation  (Bruce Momjian <bruce@momjian.us>)
Re: Inlining comparators as a performance optimisation  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Inlining comparators as a performance optimisation  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, Dec 2, 2011 at 2:35 PM, Bruce Momjian <bruce@momjian.us> wrote:
> Agreed.  Doing something once and doing something in the sort loop are
> two different overheads.

OK, so I tried to code this up.  Adding the new amproc wasn't too
difficult (see attached).  It wasn't obvious to me how to tie it into
the tuplesort infrastructure, though, so instead of wasting time
guessing what a sensible approach might be I'm going to use one of my
lifelines and poll the audience (or is that ask an expert?).
Currently the Tuplesortstate[1] has a pointer to an array of
ScanKeyData objects, one per column being sorted.  But now instead of
"FmgrInfo sk_func", the tuplesort code is going to want each scankey
to contain "SortSupportInfo(Data?) sk_sortsupport"[2], because that's
where we get the comparison function from.   Should I just go ahead
and add one more member to that struct, or is there some more
appropriate way to handle this?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

[1] Consistent capitalization is for wimps.
[2] Hey, we could abbreviate that "SSI"!  Oh, wait...

Вложения

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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Inlining comparators as a performance optimisation
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: review: CHECK FUNCTION statement