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

Re: Progress on fast path sorting, btree index creation time

From: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Progress on fast path sorting, btree index creation time
Date: 2012-01-06 00:01:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 5 January 2012 22:27, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> There is no compiler anywhere that implements "always inline", unless
> you are talking about a macro.  "inline" is a hint and nothing more,
> and if you think you can force it you are mistaken.  So this controversy
> is easily resolved: we do not need any such construct.

I'm slightly puzzled by your remarks here. GCC documentation on this
is sparse (although, as I've demonstrated, I can get better numbers
using the always_inline attribute on GCC 4.3), but take a look at

While it is not strictly true to say that pg_always_inline could
inline every function under every set of circumstances, it's pretty
close to the truth. I do accept that this facility could quite easily
be abused if its use isn't carefully measured. I also accept that
C99/GNU C inline functions are generally just requests to the compiler
that may be ignored (and indeed the compiler may inline without being
asked to).

It's short sighted to see this as a case of inlining itself making a
big difference, so much as it making a big difference as an enabling

> The real question is whether we should accept a patch that is a
> performance loss when the compiler fails to inline some reasonably
> simple function.  I think that would depend on the actual numbers
> involved, so we'd need to see data before making a decision.

Who said anything about a performance loss? Since the raw improvement
to qsort_arg is so large, it's pretty difficult to imagine a
confluence of circumstances in which this results in a net loss. See
the figures at
, for example.

The pg_always_inline idea is relatively recent. It just serves to
provide additional encouragement to the compiler to inline, insofar as
that is possible on the platform in question. The compiler's
cost/benefit analysis cannot possibly appreciate how hot a code path
qsort_arg is, because it has a set of generic heuristics that are
quite fallible, and very probably are on quite conservative. We can
appreciate such things though.

Peter Geoghegan
PostgreSQL Development, 24x7 Support, Training and Services

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-01-06 00:01:23
Subject: Re: pg_restore direct to database is broken for --insert dumps
Previous:From: Andrew DunstanDate: 2012-01-05 23:59:53
Subject: Re: pgsql: Fix breakage from earlier plperl fix.

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