Re: 9.1.3 backends getting stuck in 'startup'

On May 24, 2012, at 3:13 PM, Tom Lane wrote:

> Jeff Frost <jeff@pgexperts.com> writes:
>> On 05/24/12 12:21, Tom Lane wrote:
>=20
> Huh.  A bit bigger, but not by that much.  It doesn't seem like this
> would be enough to make seqscan performance fall off a cliff, as it
> apparently did.  Unless maybe the slightly-bloated catalogs were just a
> bit too large to fit in RAM, and so the repeated seqscans went from
> finding all their data in kernel disk buffers to finding none of it?

Seems unlikely.

>=20
>> So, interestingly, they're both quite large, but the old broken system is
>> quite a bit larger.  Any other data points be helpful?
>=20
> I think it would be interesting to get the pg_relation_size for pg_class
> plus pg_attribute plus pg_index (which I think is everything that gets
> seqscannedd in this way) on both systems, and see how those numbers
> match up to total RAM on the box.

Server has 128GB of RAM.

Currently running system:

select pg_size_pretty(pg_relation_size('pg_class'));
 pg_size_pretty=20
----------------
 181 MB
(1 row)

select pg_size_pretty(pg_relation_size('pg_index'));
 pg_size_pretty=20
----------------
 23 MB
(1 row)


Old broken system:

select pg_size_pretty(pg_relation_size('pg_class'));
 pg_size_pretty=20
----------------
 221 MB
(1 row)

select pg_size_pretty(pg_relation_size('pg_index'));
 pg_size_pretty=20
----------------
 44 MB
(1 row)

BTW, when I connected to it this time, I had a really long time before my p=
sql was able to send a query, so it seems to be still broken at least.