| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Geoghegan <pg(at)heroku(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-05 16:05:17 |
| Message-ID: | 20131205160517.GC3866@alap2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2013-12-05 10:34:16 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > I was actually thinking about making Datum (and some other types we
> > have) structs or unions. Currently it's far, far to easy to mix them. We throw
> > away pretty much all of the little typesafety C has by typedef'ing them
> > to integral types with lots of autocasting behaviour.
>
> That's intentional; on many ABIs, making Datum a struct would be
> catastrophic performance-wise because it would not be eligible for simple
> register pass or return conventions.
Unions should behave saner in that regard tho? And it be fairly easy to
make it an optional thing.
> In any case, the number of bugs I can remember that such a thing
> would've prevented is negligible.
Cases talked about upthread, where a plain datatype is returned as a
Datum instead of using FooGetDatum() and the reverse, would be
impossible. I don't think those are that infrequent?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2013-12-05 16:11:18 | Re: Performance optimization of btree binary search |
| Previous Message | Metin Doslu | 2013-12-05 16:03:16 | Re: Parallel Select query performance and shared buffers |