Re: Huge shared hit for small table - Mailing list pgsql-performance

From Jeff Janes
Subject Re: Huge shared hit for small table
Date
Msg-id CAMkU=1zjDKdXaFSihtqsRhc5RjjqC8Vr_B-RsPqf9p_UQVMS9A@mail.gmail.com
Whole thread Raw
In response to Huge shared hit for small table  (Scott Rankin <srankin@motus.com>)
Responses Re: Huge shared hit for small table  (Peter Geoghegan <pg@bowt.ie>)
Re: Huge shared hit for small table  (Scott Rankin <srankin@motus.com>)
List pgsql-performance
On Mon, Nov 4, 2019 at 2:38 PM Scott Rankin <srankin@motus.com> wrote:

Hello all,

 

We are trying to debug some slow performance in our production environment (Amazon RDS, Postgresql 9.6.11), and we’re looking at a particular EXPLAIN node that seems… weird.  This is a very large query involving a number of joins, but it performs pretty well in our staging environment (which has roughly the same data set as production, with a few tweaks).  However, there is one node in the EXPLAIN plan that is wildly different:


Could there be a long-open transaction, which is preventing hint-bits from getting on set on the table rows, as well on the index rows?

...
 

The tables in both environments are about the same size (18MB) and the indexes are about the same size (360kb/410kb) – and the shared hits are pretty much the same on the other nodes of the query between the two environments.


If this table has more turn-over than those other tables (as measured in rows, not in percentage of the table), this would not be inconsistent with my theory.
 

This has happened one time before, and we did a “REINDEX” on the program table – and that made the problem mostly go away.  Now it seems to be back, and I’m not sure what to make of it.



A reindex would not by itself fix the problem if it were the long open transaction.  But  if the long open transaction held a sufficient lock on the table, then the reindex would block until the transaction went away on its own, at which point the problem would go away on its own, so it might **appear** to have fixed the problem. 
 
Cheers,

Jeff

pgsql-performance by date:

Previous
From: Scott Rankin
Date:
Subject: Re: Huge shared hit for small table
Next
From: Peter Geoghegan
Date:
Subject: Re: Huge shared hit for small table