Re: Inlining comparators as a performance optimisation

Peter Geoghegan <peter@2ndquadrant.com>

From: Peter Geoghegan <peter@2ndquadrant.com>

To: Robert Haas <robertmhaas@gmail.com>

Cc: Tom Lane <tgl@sss.pgh.pa.us>, PG Hackers <pgsql-hackers@postgresql.org>

Date: 2011-12-01T16:44:55Z

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

Attachments

readability_inline_compar.patch (text/x-patch) patch

Attached is revision of my patch with some clean-ups. In particular,
I'm now using switch statements for greater readability, plus
supporting fast path sorting of the time datatype. I've also updated
the documentation on "Date/Time Types" to note the additional
disadvantage of using the deprecated "store timestamp + friends as
double precision floating-point numbers" compile time option.

There is one aspect to this optimisation that I haven't touched on,
which is the effect on memory consumption. I think that much of the
value that this patch will deliver will come from being able to
release sort memory earlier. Consider that the substantial
improvements in raw sorting speed (far more substantial than the
improvements in query runtime) will sometimes result in a concomitant
reduction in the time that the executor holds onto memory allocated
for sorting. Maybe the effect will only be really noticeable for plans
with a sort node as their root node, but that isn't exactly a rare
occurrence, particularly among large, expensive sorts.

-- 
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services