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

2018-06-07 12:01 GMT+02:00 Simon Riggs <simon(at)2ndquadrant(dot)com>:

> On 7 June 2018 at 06:01, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
> wrote:
> > On 7 June 2018 at 16:13, Andres Freund <andres(at)anarazel(dot)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??
>

affected rows is taken from this value on protocol level

Regards

Pavel

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