Re: computing completion tag is expensive for pgbench -S -M prepared

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: computing completion tag is expensive for pgbench -S -M prepared
Дата
Msg-id CAKJS1f-wUtWjJYdY2RYHKMsXTu7u21U5Phf=OCN8qRUrXb_2_A@mail.gmail.com
обсуждение исходный текст
Ответ на computing completion tag is expensive for pgbench -S -M prepared  (Andres Freund <andres@anarazel.de>)
Ответы Re: computing completion tag is expensive for pgbench -S -M prepared  (Simon Riggs <simon@2ndquadrant.com>)
Re: computing completion tag is expensive for pgbench -S -M prepared  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On 7 June 2018 at 16:13, Andres Freund <andres@anarazel.de> wrote:
> in PortalRun().  That's actually fairly trivial to optimize - we don't
> need the full blown snprintf machinery here.  A quick benchmark
> replacing it with:
>
>                        memcpy(completionTag, "SELECT ", sizeof("SELECT "));
>                        pg_lltoa(nprocessed, completionTag + 7);

I'd also noticed something similar with some recent benchmarks I was
doing for INSERTs into partitioned tables. In my case I saw as high as
0.7% of the time spent building the INSERT tag. So I think it's worth
fixing this.

I think it would be better to invent a function that accepts a
CmdType, int64 and Oid that copies the tag into the supplied buffer,
then make a more generic change that also replaces the code in
ProcessQuery() which builds the tag. I'm sure there must be some way
to get the CmdType down to the place you've patched so we can get rid
of the if (strcmp(portal->commandTag, "SELECT") == 0) line too.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


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

Предыдущее
От: Ashutosh Bapat
Дата:
Сообщение: Re: I'd like to discuss scaleout at PGCon
Следующее
От: Ashutosh Bapat
Дата:
Сообщение: Re: I'd like to discuss scaleout at PGCon