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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (butnot seq_tup_read)
Дата
Msg-id 20200206024824.rsrorjqurjqtoqla@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (butnot seq_tup_read)  (Kasahara Tatsuhito <kasahara.tatsuhito@gmail.com>)
Ответы Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (butnot seq_tup_read)  (Kasahara Tatsuhito <kasahara.tatsuhito@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Is custom MemoryContext prohibited?
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Assumptions about the number of parallel workers