| From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
|---|---|
| To: | Gunther <raj(at)gusw(dot)net> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks. |
| Date: | 2019-02-24 20:20:37 |
| Message-ID: | 20190224202037.GK28750@telsasoft.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Sun, Feb 24, 2019 at 12:45:34PM -0500, Gunther wrote:
> What I am most puzzled by is that no matter how long I wait, the DROP INDEX
> CONCURRENTLY never completes. Why is that?
https://www.postgresql.org/docs/11/sql-dropindex.html
CONCURRENTLY
[...] With this option, the command instead waits until conflicting transactions have completed.
Do you have a longrunning txn ? That's possibly the cause of the original
issue; vacuum cannot mark tuples as dead until txns have finished.
> I consider this ultimately a bug, or at the very least there is room for
> improvement. And I am on version 11.1.
Did you try upgrading to 11.2 ? I suspect this doesn't affect the query plan..but may be relevant?
https://www.postgresql.org/docs/11/release-11-2.html
|Improve ANALYZE's handling of concurrently-updated rows (Jeff Janes, Tom Lane)
|
|Previously, rows deleted by an in-progress transaction were omitted from ANALYZE's sample, but this has been found to lead to more inconsistency than including them would do. In effect, the sample now corresponds to an MVCC snapshot as of ANALYZE's start time.
Justin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2019-02-24 20:41:39 | Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks. |
| Previous Message | Gunther | 2019-02-24 17:45:34 | Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks. |