Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (butnot seq_tup_read)

Hi,

On Thu, Jan 30, 2020 at 10:55 AM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
> At Wed, 29 Jan 2020 23:24:09 +0900, Fujii Masao <masao.fujii@oss.nttdata.com> wrote in
> > On 2020/01/29 20:06, Kasahara Tatsuhito wrote:
> > > Although I'm not sure this behavior is really problem or not,
> > > it seems to me that previous behavior is more prefer.
> > > Is it worth to apply to HEAD and v12 branch ?
> >
> > I've not read the patch yet, but I agree that updating only seq_scan
> > but not seq_tup_read in Tid Scan sounds strange. IMO at least
> > both should be update together or neither should be updated.
>
> Basically agreed, but sample scan doesn't increment seq_scan but
> increments seq_tup_read.
Yeah, sample scan's behavior is also bit annoying.


> From the view of the view pg_stat_*_tables, the counters moves as follows.
Thanks for your clarification.

> TID scan   : yes             , seq_scan, <none>        , <none>
Here is wrong, because TID scan came to have SO_TYPE_SEQSCAN flags
from commit 147e3722f7.

So, currently( v12 and HEAD) TID scan status as following

                                                 increments
scan type    table_beginscan?, per scan, per tuple     , SO_TYPE flags
=============================================================================
TID scan   : yes             , seq_scan, <none>        , SO_TYPE_SEQSCAN

And my patch change the status to following (same as -v11)

                                                 increments
scan type    table_beginscan?, per scan, per tuple     , SO_TYPE flags
=============================================================================
TID scan   : yes             , <none>, <none>        , <none>


> I'd rather think that whatever calls table_beginscan should have
> corresponding SO_TYPE_* flags. (Note: index scan doesn't call it.)
Agreed.
It may be better to add new flag such like SO_TYPE_TIDSCAN,
and handles some statistics updating and other things.
But it may be a bit overkill, since I want to revert to the previous
behavior this time.

Best regards,
-- 
Tatsuhito Kasahara
kasahara.tatsuhito _at_ gmail.com