Re: Massive parallel queue table causes index deterioration, butREINDEX fails with deadlocks. - Mailing list pgsql-performance

From Justin Pryzby
Subject Re: Massive parallel queue table causes index deterioration, butREINDEX fails with deadlocks.
Date
Msg-id 20190224202037.GK28750@telsasoft.com
Whole thread Raw
In response to Re: Massive parallel queue table causes index deterioration, butREINDEX fails with deadlocks.  (Gunther <raj@gusw.net>)
List 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
leadto more inconsistency than including them would do. In effect, the sample now corresponds to an MVCC snapshot as of
ANALYZE'sstart time.
 

Justin


pgsql-performance by date:

Previous
From: Gunther
Date:
Subject: Re: Massive parallel queue table causes index deterioration, butREINDEX fails with deadlocks.
Next
From: Peter Geoghegan
Date:
Subject: Re: Massive parallel queue table causes index deterioration, butREINDEX fails with deadlocks.