Re: Huge shared hit for small table

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Nov 4, 2019 at 2:38 PM Scott Rankin <srankin@xxxxxxxxx> 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

[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux