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

From Tom Lane
Subject Re: Inlining comparators as a performance optimisation
Date
Msg-id 12461.1323194828@sss.pgh.pa.us
Whole thread Raw
In response to Re: Inlining comparators as a performance optimisation  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Inlining comparators as a performance optimisation
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> OK.  Well, then pushing it out to a separate file probably makes
> sense.  Do you want to do that or shall I have a crack at it?  If the
> latter, what do you think about using the name SortKey for everything
> rather than SortSupport?

I'll take another crack at it.  I'm not entirely sold yet on merging
the two structs; I think first we'd better look and see what the needs
are in the other potential callers I mentioned.  If we'd end up
cluttering the struct with half a dozen weird fields, it'd be better to
stick to a minimal interface struct with various wrapper structs, IMO.

OTOH it did seem that the names were getting a bit long.  If we do
keep the two-struct-levels approach, what do you think of
s/SortSupportInfo/SortSupport/g ?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: xlog location arithmetic
Next
From: Robert Haas
Date:
Subject: Re: Inlining comparators as a performance optimisation