Re: Inlining comparators as a performance optimisation

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Inlining comparators as a performance optimisation
Дата
Msg-id CA+TgmoZbeZV+wrJEu=JKgRfH9Yk6ifv2__XZuOkAErd9T8kRFQ@mail.gmail.com
обсуждение исходный текст
Ответ на 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 Tue, Dec 6, 2011 at 8:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 1. Adding sortsupport infrastructure for more datatypes.
> 2. Revising nbtree and related code to use this infrastructure.
> 3. Integrating Peter's work into this framework.
>
> I'll try to take care of #1 for at least a few key datatypes before
> I commit, but I think #2 is best done as a separate patch, so I'll
> postpone that till later.

I see you've committed a chunk of this now.  Does it make sense to do
#1 for every data type we support, or should we be more selective than
that?  My gut feeling would be to add it across the board and
introduce an opr_sanity check for it.  The general utility of adding
it to deprecated types like abstime is perhaps questionable, but it
strikes me that the value of making everything consistent probably
outweighs the cost of a few extra lines of code.

Are you planning to do anything about #2 or #3?

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


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

Предыдущее
От: Marti Raudsepp
Дата:
Сообщение: Re: pg_stat_statements with query tree based normalization
Следующее
От: "Albe Laurenz"
Дата:
Сообщение: Re: review: CHECK FUNCTION statement