Re: Sort support for macaddr8
От | Andres Freund |
---|---|
Тема | Re: Sort support for macaddr8 |
Дата | |
Msg-id | 20190606191440.26knu2gdqmi2fksr@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Sort support for macaddr8 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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
В списке pgsql-hackers по дате отправления: