ks ago but
didn't check if a reindex is necessary yet. Table pg_stat_user_indexes
currently lists 672,244 indexes. But I don't see how this will help with
the query I posted that almost takes 13 minutes to finish.
Best regards
Ulf
On Sun, Sep 19, 2021 at 2:06 PM Ranier Vilela wrote:
>
Hi there,
A database cluster (PostgreSQL 12.4 running on Amazon Aurora @
db.r5.xlarge) with a single database of mine consists of 1,656,618 rows in
pg_class. Using pg_dump on that database leads to excessive memory usage
and sometimes even a kill by signal 9:
2021-09-18 16:51:24 UTC::@:[29787]:LO
>
> It seems plausible to guess that you've hit some behavior that's O(N^2)
> in the number of objects (for some object type or other). Perhaps "perf"
> or a similar tool would give some insight into where the bottleneck is.
>
> https://wiki.postgresql.org/wiki/Profiling_with_perf
Thanks for you
2017-12-07 17:01 GMT+01:00 Tom Lane :
> =?UTF-8?Q?Ulf_Lohbr=C3=BCgge?= writes:
> > I could reproduce part of the things I described earlier in this thread.
> A
> > guy named Andriy Senyshyn mailed me after reading this thread here (he
> > could somehow not join the mailing list) and observed a di
min are pretty
fast (below 1 ms).
I further wonder what those log statements "rehashing catalog cache..." do
and if they are the cause of the slow execution.
So this does not reproduce my observed query times >2000ms but is maybe a
hint for other things that might be worth looking int
