Re: Performance optimization of btree binary search

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Geoghegan <pg(at)heroku(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>
Subject: Re: Performance optimization of btree binary search
Date: 2013-12-04 23:45:47
Message-ID: 28590.1386200747@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Geoghegan <pg(at)heroku(dot)com> writes:
> On Wed, Dec 4, 2013 at 1:59 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> Yeah, I think if we can make something like this work, it would be
>> neat-o. Getting this working for int4 would be a good win, as Peter
>> says, but getting it working for both int4 and int8 with the same code
>> would be a significantly better one.

> No arguments here. I think I didn't initially suggest it myself out of
> passing concern about the guarantees around how unused Datum bits are
> initialized in all relevant contexts, but having looked at it for a
> second I see that we are of course disciplined there.

Hm ... actually, the comment at lines 335ff of postgres.h points out that
a Datum returned from a version 0 user-defined function might contain
garbage in the high order bits. We could fix that, probably, with some
cleanup code added to fmgr_oldstyle. It'd waste a few cycles ... but if
there's anybody out there who still cares about the performance of such
functions, it's high time they fixed them to be v1, anyway.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-12-04 23:48:44 Re: Performance optimization of btree binary search
Previous Message Peter Geoghegan 2013-12-04 23:33:23 Re: Performance optimization of btree binary search