From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Sort support for macaddr8 |
Date: | 2019-06-06 19:14:40 |
Message-ID: | 20190606191440.26knu2gdqmi2fksr@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2019-06-06 13:39:50 -0400, Tom Lane wrote:
> Lastly, I don't think adding additional allowed widths of pass-by-value
> types would be cost-free, because it would add cycles to the inner loops
> of the tuple forming and deforming functions.
I'm not sure I quite buy that.
I think that we have branches over a fixed number of lengths is largely
unnecessary. att_addlength_pointer() doesn't care - it just uses the
length. And I think we should just consider doing the same for
fetch_att(). E.g. by using memcpy().
That'd also have the advantage that we'd not be *forced* to rely
alignment of byval types. The only reason we actually need that is the
heaptuple-to-struct mapping for catalogs. Outside of that we don't have
pointers to individual byval tuples, and waste a fair bit of padding due
to that.
Additionally we'd get rid of needing separate versions for SIZEOF_DATUM
!= 8/not.
> (No, I don't believe that JIT makes that an ignorable concern.)
Obviously not.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2019-06-06 19:36:03 | Re: Should we warn against using too many partitions? |
Previous Message | Fabrízio de Royes Mello | 2019-06-06 19:03:48 | Re: Add CREATE DATABASE LOCALE option |