Re: pgsql: Move pg_stat_statements query jumbling to core.

On Thu, Apr 8, 2021 at 11:40 AM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
>
> On Thu, Apr 08, 2021 at 01:22:49PM +0800, Julien Rouhaud wrote:
> > Le jeu. 8 avr. 2021 à 13:17, Andres Freund <andres(at)anarazel(dot)de> a écrit :
> >
> > >
> > > This - or something in the vicinity - seems to break running the
> > > regression tests with force_parallel_mode=regress. There's lots of
> > > differences like
> > >
> > > SELECT query, calls, rows FROM pg_stat_statements ORDER BY query COLLATE
> > > "C";
> > > query
> > > | calls | rows
> > >
> > > ------------------------------------------------------------------------------+-------+------
> > > SELECT (i + $2 + $3)::INTEGER
> > > | 2 | 2
> > > SELECT (i + $2)::INTEGER LIMIT $3
> > > | 2 | 2
> > > - SELECT PLUS_ONE($1)
> > > | 2 | 2
> > > - SELECT PLUS_TWO($1)
> > > | 2 | 2
> > > - SELECT pg_stat_statements_reset()
> > > | 1 | 1
> > > + SELECT PLUS_ONE($1)
> > > | 4 | 4
> > > + SELECT PLUS_TWO($1)
> > > | 4 | 4
> > > + SELECT pg_stat_statements_reset();
> >
> > oh, I think it's because parallel workers now have the queryid of the main
> > query. Probably ignoring parallel workers in the executor end hook will fix
> > the problem. I'll look at it as soon as I will be back home.
>
> That was indeed the problem. I think the best is to entirely ignore parallel
> workers in pg_stat_statements,
>

I haven't studied this patch but I have a question here. We normally
do accumulate the stats from parallel workers for the purpose of
Explain Analyze, so won't ignoring them in pg_stat_statements a bit
inconsistent but if that is the case even before this patch then that
might be fine?

--
With Regards,
Amit Kapila.