Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group