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

On 2018-06-07 20:34:39 +0100, Simon Riggs wrote: > On 7 June 2018 at 20:27, Tom Lane wrote: > > Simon Riggs writes: > >> If we're going to compress the protocol, it seems sensible to remove > >> extraneous information first. > > > > Breaking the wire protocol was nowhere in this thread. > > No,

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

On 7 June 2018 at 20:27, Tom Lane wrote: > Simon Riggs writes: >> If we're going to compress the protocol, it seems sensible to remove >> extraneous information first. > > Breaking the wire protocol was nowhere in this thread. No, it wasn't. But there is another thread on the subject of

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

Simon Riggs writes: > If we're going to compress the protocol, it seems sensible to remove > extraneous information first. Breaking the wire protocol was nowhere in this thread. regards, tom lane

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

On 7 June 2018 at 19:20, Andres Freund wrote: > On 2018-06-07 11:40:48 +0100, Simon Riggs wrote: >> On 7 June 2018 at 11:29, Pavel Stehule wrote: >> >> >> Do we actually need the completion tag at all? In most cases?? >> > >> > >> > affected rows is taken from this value on protocol level >> >>

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

On 2018-06-07 17:01:47 +1200, David Rowley wrote: > On 7 June 2018 at 16:13, Andres Freund 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: > > > >

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

On 2018-06-07 10:30:14 -0400, Tom Lane wrote: > Andres Freund writes: > > ... 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 ",

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

Andres Freund writes: > ... 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,

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

On 7 June 2018 at 11:29, Pavel Stehule wrote: >> Do we actually need the completion tag at all? In most cases?? > > > affected rows is taken from this value on protocol level I didn't mean we should remove the number of rows. Many things rely on that. -- Simon Riggs

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

2018-06-07 12:01 GMT+02:00 Simon Riggs : > On 7 June 2018 at 06:01, David Rowley > wrote: > > On 7 June 2018 at 16:13, Andres Freund wrote: > >> in PortalRun(). That's actually fairly trivial to optimize - we don't > >> need the full blown snprintf machinery here. A quick benchmark > >>

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

On 7 June 2018 at 06:01, David Rowley wrote: > On 7 June 2018 at 16:13, Andres Freund 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: >> >>

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

On 7 June 2018 at 16:13, Andres Freund 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 ")); >

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

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,