Re: Why is pq_begintypsend so slow?

Поиск
Список
Период
Сортировка
От David Fetter
Тема Re: Why is pq_begintypsend so slow?
Дата
Msg-id 20200112014107.GC32763@fetter.org
обсуждение исходный текст
Ответ на Re: Why is pq_begintypsend so slow?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Why is pq_begintypsend so slow?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sat, Jan 11, 2020 at 03:19:37PM -0500, Tom Lane wrote:
> 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?

Please find attached a patch that does it both of the things you
suggested.

Best,
David.
-- 
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: [Proposal] Global temporary tables
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: [Proposal] Global temporary tables