From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: SendRowDescriptionMessage() is slow for queries with a lot of columns |
Date: | 2017-09-28 04:31:00 |
Message-ID: | 9691A673-3883-48EB-9CB0-B46507C6003F@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On September 27, 2017 9:06:49 PM PDT, Andres Freund <andres(at)anarazel(dot)de> wrote:
>On 2017-09-28 00:01:53 -0400, Tom Lane wrote:
>> Andres Freund <andres(at)anarazel(dot)de> writes:
>> > Attached is an extension of the already existing pg_bswap.h that
>> > a) adds 16 bit support
>> > b) moves everything to inline functions, removing multiple
>evaluation
>> > hazards that were present everywhere.
>> > c) adds pg_nto{s,l,ll} and pg_hton{s,l,ll} wrappers that only do
>work
>> > if necessary.
>>
>> Could we please not perpetuate the brain-dead "s" and "l" suffixes
>> on these names? Given the lack of standardization as to how long
>> "long" is, that's entirely unhelpful. I'd be fine with names like
>> pg_ntoh16/32/64 and pg_hton16/32/64.
>
>Yes. I'd polled a few people and they leaned towards those. But I'm
>perfectly happy to do that renaming.
If somebody wants to argue for replacing hton/ntoh with {to,from}big or *be, now's the time.
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2017-09-28 04:58:33 | Re: path toward faster partition pruning |
Previous Message | Andres Freund | 2017-09-28 04:06:49 | Re: SendRowDescriptionMessage() is slow for queries with a lot of columns |