Re: BUG #18177: certain queries under certain contexts take multiple orders of magnitude longer compared to v10

On Thu, 2 Nov 2023 at 21:56, PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:
> I cannot claim to understand the bug that is causing this issue, so the best
> I can do is simply provide the explain output and try to keep from providing
> confusing details, because this is outside the realm of my expertise:

> (' -> Index Scan using
> "DataRepo_peakdata_peak_group_id_4dd87f4a" on "DataRepo_peakdata"
> (cost=0.25..8.26 rows=1 width=8) (actual time=0.017..7.149 rows=7896
> loops=1)',)

Nothing looks particularly bug like so far. It seems the
pg_class.reltuples estimate for this relation is way out.

Has autovacuum gotten to this table recently?

select * from pg_stat_user_tables where relid = '"DataRepo_peakdata"'::regclass;

The plan would likely come good if you analyzed that table. You
should see if you can figure out why autovacuum hasn't analyzed it.

For the future, it might be best to post EXPLAIN output as an
attachment. The extra formatting makes it difficult to read.

David