Re: BUG #18177: certain queries under certain contexts take multiple orders of magnitude longer compared to v10
От | David Rowley |
---|---|
Тема | Re: BUG #18177: certain queries under certain contexts take multiple orders of magnitude longer compared to v10 |
Дата | |
Msg-id | CAApHDvrRgDpV19MDNZ-0Tou-F2+cTU6ZNPq3rixUGp_kuw6-9Q@mail.gmail.com обсуждение исходный текст |
Ответ на | BUG #18177: certain queries under certain contexts take multiple orders of magnitude longer compared to v10 (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #18177: certain queries under certain contexts take multiple orders of magnitude longer compared to v10
Re: BUG #18177: certain queries under certain contexts take multiple orders of magnitude longer compared to v10 |
Список | pgsql-bugs |
On Thu, 2 Nov 2023 at 21:56, PG Bug reporting form <noreply@postgresql.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
В списке pgsql-bugs по дате отправления: