Hi,
On Thu, Jan 30, 2020 at 10:55 AM Kyotaro Horiguchi
<horikyota....@gmail.com> wrote:
> At Wed, 29 Jan 2020 23:24:09 +0900, Fujii Masao <masao.fu...@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
