Re: BUG #17693: Slow performance: Much slower queries on pg_stat_all_tables since 13.4

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: BUG #17693: Slow performance: Much slower queries on pg_stat_all_tables since 13.4
Дата
Msg-id 20221128211639.cbtsahgwlxh33xf5@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: BUG #17693: Slow performance: Much slower queries on pg_stat_all_tables since 13.4  (Greg Stark <stark@mit.edu>)
Список pgsql-bugs
Hi,

On 2022-11-23 14:13:56 -0500, Greg Stark wrote:
> That said, this 5s delay does seem pretty odd.

Could just be a network configuration issue. In < 15 getting the stats
collector to write out a stats file requires sending a ping message via udp -
which obviously can get lost.

How many schema objects are in that database? I'd try to use pg_ls_dir() etc
to see how large the stats files are - but you might not be permitted to do so
in RDS.

If the file is large, the reads for it could end up being a significant source
of overall IO and you're just seeing the effects of running into disk
throughput limits.

If you're querying pg_stat* very frequently, it might be worth using explicit
transactions, to avoid each query getting a new snapshot of the stats.


> > Just to check, I did create a database with 100K tables in community
> > Postgres 13.9, and I didn't see any odd behavior with selecting from
> > pg_stat_all_tables.
> 
> Note that he also has about 1.7M indexes... :)

I assume that's based on the IOS cost estimate on pg_index_indrelid_index?

Greetings,

Andres Freund



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #17700: An assert failed in prepjointree.c
Следующее
От: Robert KOFLER
Дата:
Сообщение: daterange() is ignoring 3rd boundaries argument