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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: aless(dot)jeant(at)gmail(dot)com
Cc: 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-23 16:41:48
Message-ID: 3715055.1669221708@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> We did a point upgrade through RDS's managed service which went from 13.4 to
> 13.7. (13.9 is unavailable and we have yet to upgrade to 13.8 - however I
> couldn't find any documentation or issue history reporting similar symptoms
> in the past year of discussions here)

> This created a weird bug which is causing a lot of strain on our systems,
> because we currently run a lot of queries over the pg_stat_all_tables, in
> order to choose candidate tables most appropriate to vacuum preemptively in
> a production system (we have a lot of active tables, order of magnitude 100k
> tables)

> Before this, queries would take <<1 second, now they're always ~5 seconds,
> regardless of what we are filtering on.

RDS is not Postgres; the underlying storage engine is completely
different, as a consequence of which the Postgres layer is pretty
heavily modified (or so we in the community assume, having never
seen any of their source code). I think you need to take this up
with Amazon.

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.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Greg Stark 2022-11-23 19:13:56 Re: BUG #17693: Slow performance: Much slower queries on pg_stat_all_tables since 13.4
Previous Message Tom Lane 2022-11-23 16:20:26 Re: Unexpected behaviour of a RAISE statement in an IMMUTABLE function