Re: Massive parallel queue table causes index deterioration, butREINDEX fails with deadlocks.
| От | Jeff Janes |
|---|---|
| Тема | Re: Massive parallel queue table causes index deterioration, butREINDEX fails with deadlocks. |
| Дата | |
| Msg-id | CAMkU=1z03uq-GHQ+Dgv7ksEVyTA6QzAbSkxVmj3GK-WGK2W=gw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Massive parallel queue table causes index deterioration, butREINDEX fails with deadlocks. (Gunther <raj@gusw.net>) |
| Ответы |
Re: Massive parallel queue table causes index deterioration, butREINDEX fails with deadlocks.
Re: Massive parallel queue table causes index deterioration, butREINDEX fails with deadlocks. |
| Список | pgsql-performance |
On Sun, Feb 24, 2019 at 1:02 PM Gunther <raj@gusw.net> wrote:
Thank you all for responding so far.
David Rowley and Justin Pryzby suggested things about autovacuum. But I don't think autovacuum has any helpful role here. I am explicitly doing a vacuum on that table. And it doesn't help at all. Almost not at all.
If you do a vacuum verbose, what stats do you get back? What is the size of the index when the degradation starts to show, and immediately after a successful reindex?
Also, how is JobID assigned? Are they from a sequence, or some other method where they are always added to the end of the index's keyspace?
When it starts to degrade, what is the EXPLAIN plan for the query?
Cheers,
Jeff
В списке pgsql-performance по дате отправления: