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

From: Andres Freund <andres(at)anarazel(dot)de>
To: Kasahara Tatsuhito <kasahara(dot)tatsuhito(at)gmail(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (but not seq_tup_read)
Date: 2020-02-06 02:48:24
Message-ID: 20200206024824.rsrorjqurjqtoqla@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(dot)tatsuhito(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2020-02-06 02:50:29 Re: Assumptions about the number of parallel workers
Previous Message Kyotaro Horiguchi 2020-02-06 02:46:38 Re: Is custom MemoryContext prohibited?