Re: Inlining comparators as a performance optimisation

From: Greg Jaskiewicz <gj(at)pointblue(dot)com(dot)pl>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Inlining comparators as a performance optimisation
Date: 2011-11-29 21:43:40
Message-ID: EF6F6E8D-144E-4B5B-9A05-33BF8EC04C65@pointblue.com.pl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 28 Nov 2011, at 02:15, Peter Geoghegan wrote:

> Attached are the results from performing a similar process to the
> prior benchmark, but on Greg Smith's high-end server, and with an
> orderlines table that has been "doubled-up" until it is 1538 MB,
> making the same old query perform a quicksort that's over 3GB. Short
> version: HEAD is 20468.0ms, with my patch it's 13689.698ms, so these
> gains hold-up very well for very large in-memory sorts, possibly even
> perfectly.
>

This is some really good stuff.
Has to be said, that there must be quite few other places where inlining like that could have quite a positive benefit.
But - I also have to say that both template functions and template classes in C++ give you pretty much the same speed improvement, with much better clarity and readability of the code. (I've tested it with the example Peter presented, if someone is interested in the code).
One more reason why PostgreSQL project should look into the future and get some of the bits simplified and optimised by switching to C++.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dan Ports 2011-11-29 21:44:28 autovacuum and default_transaction_isolation
Previous Message Andres Freund 2011-11-29 21:36:26 Re: Inlining comparators as a performance optimisation