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

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Geoghegan <peter(at)2ndquadrant(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Progress on fast path sorting, btree index creation time
Date: 2012-01-05 22:27:28
Message-ID: 21987.1325802448@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Dec 29, 2011 at 9:03 PM, Peter Geoghegan <peter(at)2ndquadrant(dot)com> wrote:
>> The first (controversy A) is that I have added a new
>> piece of infrastructure, pg_always_inline, which, as the name
>> suggests, is a portable way of insisting that a function should be
>> invariably inlined.

> I don't have a problem with the idea of a pg_always_inline, but I'm
> wondering what sort of fallback mechanism you propose.

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.

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.

>> The second
>> possible point of contention (controversy B) is that I have jettisoned
>> various protections against bad qsort implementations that I believe
>> are a legacy of when we used the system qsort pre-2006, that can no
>> longer be justified.

No objection to that one, I think, as long as you've verified that our
implementation is in fact okay about these things.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2012-01-05 22:30:09
Subject: Re: [COMMITTERS] pgsql: Work around perl bug in SvPVutf8().
Previous:From: Tom LaneDate: 2012-01-05 22:19:54
Subject: Re: FATAL: bogus data in lock file "postmaster.pid": ""

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