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
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 |