Re: computing completion tag is expensive for pgbench -S -M prepared
От | Simon Riggs |
---|---|
Тема | Re: computing completion tag is expensive for pgbench -S -M prepared |
Дата | |
Msg-id | CANP8+jL22Y0YwKPGFCaCXuKuHRD=qxFHW=pviPr5aOEH5z84RQ@mail.gmail.com обсуждение исходный текст |
Ответ на | 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
|
Список | pgsql-hackers |
On 7 June 2018 at 06:01, David Rowley <david.rowley@2ndquadrant.com> wrote: > 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. Sounds better Do we actually need the completion tag at all? In most cases?? Perhaps we should add a parameter to make it optional and turn it off by default, except for psql. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: