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

From Andres Freund
Subject Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (butnot seq_tup_read)
Date
Msg-id 20200206024824.rsrorjqurjqtoqla@alap3.anarazel.de
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)
List pgsql-hackers
Hi,

On 2020-02-05 16:25:25 +0900, Kasahara Tatsuhito wrote:
> On Mon, Feb 3, 2020 at 6:20 PM Kasahara Tatsuhito
> <kasahara.tatsuhito@gmail.com> wrote:
> > Therefore, from v12, Tid scan not only increases the value of
> > seq_scan, but also acquires a predicate lock.
> 
> Based on further investigation and Fujii's advice, I've summarized
> this issue as follows.
> 
> From commit 147e3722f7, Tid Scan came to
> (A) increments num of seq_scan on pg_stat_*_tables
> and
> (B) take a predicate lock on the entire relation.
> 
> (A) may be confusing to users, so I think it is better to fix it.
> For (B), an unexpected serialization error has occurred as follows, so
> I think it should be fix.

I think it'd be good if we could guard against b) via an isolation
test. It's more painful to do that for a), due to the unreliability of
stats at the moment (we have some tests, but they take a long time).

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Is custom MemoryContext prohibited?
Next
From: Andres Freund
Date:
Subject: Re: Assumptions about the number of parallel workers