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
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 |