From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Peter Geoghegan <pg(at)heroku(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-05 12:20:47 |
Message-ID: | 20131205122047.GD12398@alap2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2013-12-04 18:48:44 -0500, Robert Haas wrote:
> * When a type narrower than Datum is stored in a Datum, we place it in the
> * low-order bits and are careful that the DatumGetXXX macro for it discards
> * the unused high-order bits (as opposed to, say, assuming they are zero).
> * This is needed to support old-style user-defined functions, since depending
> * on architecture and compiler, the return value of a function returning char
> * or short may contain garbage when called as if it returned Datum.
>
> And record_image_eq does a rather elaborate dance around here, calling
> the appropriate GET_x_BYTES macro depending on the type-width. If we
> can really count on the high-order bits to be zero, that's all
> completely unnecessary tomfoolery.
I don't think we can get rid of that dance in record_image_eq - it very
well could used on records originally generated when those bits haven't
been guaranteed to be zeroed.
Other usecases where the appropriate DatumGetFoo() macros are used don't
have a problem with that since it's cleared again there, but in
record_image_eq we can't rely on that.
Or am I missing something?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Golub | 2013-12-05 12:30:57 | Re: Proposal: variant of regclass |
Previous Message | MauMau | 2013-12-05 12:07:30 | Re: [bug fix] "pg_ctl stop" times out when it should respond quickly |