Re: backend suddenly becomes slow, then remains slow - Mailing list pgsql-performance

From Jeff Janes
Subject Re: backend suddenly becomes slow, then remains slow
Date
Msg-id CAMkU=1zCqx-EpWZz1QmR0d5vYC_=ETfni52CDRJ2Zj_LK3SkBg@mail.gmail.com
Whole thread Raw
In response to Re: backend suddenly becomes slow, then remains slow  (Andrew Dunstan <andrew.dunstan@pgexperts.com>)
List pgsql-performance
On Thursday, December 27, 2012, Andrew Dunstan wrote:
On 12/26/2012 11:03 PM, Jeff Janes wrote:

Do you have a huge number of tables?  Maybe over the course of a long-lived connection, it touches enough tables to bloat the relcache / syscache.  I don't know how the autovac would be involved in that, though.



Yes, we do indeed have a huge number of tables. This seems a plausible thesis.

All of the syscache things have compiled hard-coded numbers of buckets, at most 2048, and once those are exceeded the resulting collision resolution becomes essentially linear.  It is not hard to exceed 2048 tables by a substantial multiple, and even less hard to exceed 2048 columns (summed over all tables).

I don't know why syscache doesn't use dynahash; whether it is older than dynahash is and was never converted out of inertia, or if there are extra features that don't fit the dynahash API.  If the former, then converting them to use dynahash should give automatic resizing for free.  Maybe that conversion should be a To Do item?



Cheers,

Jeff

pgsql-performance by date:

Previous
From: Nikolas Everett
Date:
Subject: Re: explain analyze reports that my queries are fast but they run very slowly
Next
From: Jeff Janes
Date:
Subject: Re: Why does the query planner use two full indexes, when a dedicated partial index exists?