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

From: Andres Freund <andres(at)anarazel(dot)de>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, aless(dot)jeant(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17693: Slow performance: Much slower queries on pg_stat_all_tables since 13.4
Date: 2022-11-28 21:16:39
Message-ID: 20221128211639.cbtsahgwlxh33xf5@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Robert KOFLER 2022-11-28 23:50:51 daterange() is ignoring 3rd boundaries argument
Previous Message Tom Lane 2022-11-28 16:22:07 Re: BUG #17700: An assert failed in prepjointree.c