| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | Gunther <raj(at)gusw(dot)net> |
| Cc: | postgres performance list <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks. |
| Date: | 2019-02-24 23:39:57 |
| Message-ID: | CAMkU=1z03uq-GHQ+Dgv7ksEVyTA6QzAbSkxVmj3GK-WGK2W=gw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Sun, Feb 24, 2019 at 1:02 PM Gunther <raj(at)gusw(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gunther Schadow | 2019-02-25 03:06:02 | Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks. |
| Previous Message | Jeff Janes | 2019-02-24 23:33:19 | Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks. |