Re: Inlining comparators as a performance optimisation - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Inlining comparators as a performance optimisation
Date
Msg-id CA+TgmoZbeZV+wrJEu=JKgRfH9Yk6ifv2__XZuOkAErd9T8kRFQ@mail.gmail.com
Whole thread Raw
In response to Re: Inlining comparators as a performance optimisation  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Inlining comparators as a performance optimisation  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Marti Raudsepp
Date:
Subject: Re: pg_stat_statements with query tree based normalization
Next
From: "Albe Laurenz"
Date:
Subject: Re: review: CHECK FUNCTION statement