Re: SendRowDescriptionMessage() is slow for queries with a lot of columns

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: SendRowDescriptionMessage() is slow for queries with a lot of columns
Date: 2017-09-27 17:20:19
Message-ID: 20170927172019.gheidqy6xvlxb325@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2017-09-13 23:34:18 -0700, Andres Freund wrote:
> I'm not yet super sure about the implementation. For one, I'm not
> sure this shouldn't instead be stringinfo.h functions, with very very
> tiny pqformat.h wrappers. But conversely I think it'd make a lot of
> sense for the pqformat integer functions to get rid of the
> continually maintained trailing null-byte - I was hoping the compiler
> could optimize that away, but alas, no luck. As soon as a single
> integer is sent, you can't rely on 0 terminated strings anyway.

I'd been wondering about missing CPU optimizations after the patch, and
hunted it down. Turns out the problem is that htons/ntohs are, on pretty
much all glibc versions, implemented using inline assembler. Which in
turns allows the compiler very little freedom to perform optimizations,
because it doesn't know what's actually happening.

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.

This'll allow the later patches to allow the compiler to perform the
relevant optimizations. It also allows to optimize e.g. pq_sendint64()
to avoid having to do multiple byteswaps.

Greetings,

Andres Freund

Attachment Content-Type Size
0001-Extend-revamp-pg_bswap.h-infrastructure.patch text/x-diff 7.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-09-27 17:28:22 Re: Binary search in fmgr_isbuiltin() is a bottleneck.
Previous Message Michael Banck 2017-09-27 17:15:59 Re: Create replication slot in pg_basebackup if requested and not yet present