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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема computing completion tag is expensive for pgbench -S -M prepared
Дата
Msg-id 20180607041341.37swzwqluyfendjl@alap3.anarazel.de
обсуждение исходный текст
Ответы Re: computing completion tag is expensive for pgbench -S -M prepared  (David Rowley <david.rowley@2ndquadrant.com>)
Re: computing completion tag is expensive for pgbench -S -M prepared  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

While looking at a profile I randomly noticed that we spend a surprising
amount of time in snprintf() and its subsidiary functions. That turns
out to be
                    if (strcmp(portal->commandTag, "SELECT") == 0)
                        snprintf(completionTag, COMPLETION_TAG_BUFSIZE,
                                 "SELECT " UINT64_FORMAT, nprocessed);

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);

yields nearly a ~2% increase in TPS. Larger than I expected.  The code
is obviously less pretty, but it's also not actually that bad.

Attached is the patch I used for benchmarking. I wonder if I just hit
some specific version of glibc that regressed snprintf performance, or
whether others can reproduce this.

If it actually reproducible, I think we should go for it. But update the
rest of the completionTag writes in the same file too.

Greetings,

Andres Freund

Вложения

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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Needless additional partition check in INSERT?
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: SCRAM with channel binding downgrade attack