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+Tgmob1BE2ACXTFRtH9RFqgqc8UjK9mu6ccyEen-XD+pai5=Q@mail.gmail.com
Whole thread Raw
In response to Re: Inlining comparators as a performance optimisation  (Peter Geoghegan <peter@2ndquadrant.com>)
Responses Re: Inlining comparators as a performance optimisation  (Greg Smith <greg@2ndQuadrant.com>)
List pgsql-hackers
On Wed, Dec 7, 2011 at 10:58 AM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
> On 7 December 2011 15:15, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Wed, Dec 7, 2011 at 10:09 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> But it would still have to be prepared for detoasting,
>>> so in the end I was unenthused.  Anyone who feels like testing could try
>>> to prove me wrong about it though.
>>
>> I think that'd definitely be worth investigating (although I'm not
>> sure I have the time to do it myself any time real soon).
>
> I'll at least take a look at it. Sorting text is a fairly common case.
> I'm not hugely enthused about spending too much time on work that will
> only be useful if collate_is_c.

Well, text_pattern_ops is not exactly an uncommon case, but sure.  And
there might be some benefit for other collations, too.

>> Cool.  Peter, can you rebase your patch and integrate it into the
>> sortsupport framework that's now committed?
>
> Yes, I'd be happy to, though I don't think I'm going to be getting
> around to it this side of Friday. Since it isn't a blocker, I assume
> that's okay.

Sounds fine to me.

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


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Inlining comparators as a performance optimisation
Next
From: Jaime Casanova
Date:
Subject: Re: Measuring relation free space