Re: Inlining comparators as a performance optimisation
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <bruce@momjian.us>, Peter Geoghegan <peter@2ndquadrant.com>, PG Hackers <pgsql-hackers@postgresql.org>
Date: 2011-12-06T18:08:29Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Speed up conversion of signed integers to C strings.
- 4fc115b2e981 9.1.0 cited
-
Remove some unnecessary tests of pgstat_track_counts.
- f4d242ef9473 9.1.0 cited
-
Remove cvs keywords from all files.
- 9f2e21138693 9.1.0 cited
-
Code cleanup for function prototypes: change two K&R-style prototypes
- b9954fbb4ef2 8.3.0 cited
-
Use Min() instead of min() in qsort, for consistency and to avoid
- b38900c76776 8.2.0 cited
-
pgindent run for 8.2.
- f99a569a2ee3 8.2.0 cited
-
Switch over to using our own qsort() all the time, as has been proposed
- 6edd2b4a91bd 8.2.0 cited
On Tue, Dec 6, 2011 at 1:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. OK. I'll defer to whatever you come up with after looking at it. > 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 ? +1. I had that thought when you originally suggested that name, but it didn't seem worth arguing about. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company