From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Janes <jeff.janes@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Why is pq_begintypsend so slow?
Date: Sat, 11 Jan 2020 15:19:37 -0500
Message-ID: <31795.1578773977@sss.pgh.pa.us> (raw)
In-Reply-To: <CAMkU=1whbRDUwa4eayD9+59K-coxO9senDkPRbTn3cg0pUz4AQ@mail.gmail.com>
References: <CAMkU=1whbRDUwa4eayD9+59K-coxO9senDkPRbTn3cg0pUz4AQ@mail.gmail.com>
Jeff Janes <jeff.janes@gmail.com> writes:
> I saw that the hotspot was pq_begintypsend at 20%, which was twice the
> percentage as the next place winner (AllocSetAlloc).
Weird.
> Why is this such a bottleneck?
Not sure, but it seems like a pretty dumb way to push the stringinfo's
len forward. We're reading/updating the len word in each line, and
if your perf measurements are to be believed, it's the re-fetches of
the len values that are bottlenecked --- maybe your CPU isn't too
bright about that? The bytes of the string value are getting written
twice too, thanks to uselessly setting up a terminating nul each time.
I'd be inclined to replace the appendStringInfoCharMacro calls with
appendStringInfoSpaces(buf, 4) --- I don't think we care exactly what
is inserted into those bytes at this point. And maybe
appendStringInfoSpaces could stand some micro-optimization, too.
Use a memset and a single len adjustment, perhaps?
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, jeff.janes@gmail.com
Subject: Re: Why is pq_begintypsend so slow?
In-Reply-To: <31795.1578773977@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox