Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (butnot seq_tup_read) - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (butnot seq_tup_read)
Date
Msg-id 8db45a89-0bd9-c1a8-0ce3-99b71c26b7ae@oss.nttdata.com
Whole thread Raw
In response to Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (butnot seq_tup_read)  (Kasahara Tatsuhito <kasahara.tatsuhito@gmail.com>)
Responses Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (butnot seq_tup_read)
Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (butnot seq_tup_read)
List pgsql-hackers

On 2020/02/07 15:07, Kasahara Tatsuhito wrote:
> Hi,
> 
> On Fri, Feb 7, 2020 at 1:27 PM Kyotaro Horiguchi
> <horikyota.ntt@gmail.com> wrote:
>> It seems that nkeys and key are useless. Since every table_beginscan_*
>> functions have distinct parameter sets, don't we remove them from
>> table_beginscan_tid?
> Yeah, actually, when calling table_beginscan_tid(), nkeys is set to 0
> and * key is set to NULL,
> so these are not used at the moment.
> 
> I removed unnecessary arguments from table_beginscan_tid().
> 
> Attache the v5 patch.

Thanks for updating the patch! The patch looks good to me.
So barring any objection, I will push it and back-patch to v12 *soon*
so that the upcoming minor version can contain it.

BTW, commit 147e3722f7 causing the issue changed currtid_byreloid()
and currtid_byrelname() so that they also call table_beginscan().
I'm not sure what those functions are, but probably we should fix them
so that table_beginscan_tid() is called instead. Thought?

Regards,

-- 
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: In PG12, query with float calculations is slower than PG11
Next
From: Amit Langote
Date:
Subject: Re: In PG12, query with float calculations is slower than PG11