Re: pg_stat_*_columns? - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: pg_stat_*_columns?
Date
Msg-id 558DEB42.9070307@2ndquadrant.com
Whole thread Raw
In response to Re: pg_stat_*_columns?  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers

On 06/27/2015 12:30 AM, Jim Nasby wrote:
> On 6/24/15 6:41 PM, Tomas Vondra wrote:
>>> Were the stories (or the experience which lead to the stories) on
>>> 9.3 or later? Do they have a good way to reproduce it for testing
>>> purposes?
>>
>> The per-db split can only improve things if there actually are
>> multiple databases, and if the objects are somehow evenly
>> distributed among them. If there's a single database, or if most of
>> the objects are in a single database (but stored in multiple
>> schemas, for example), it does not help much. So it's trivially to
>> reproduce the previous issues.
>
> Right, and a single large database is a pretty common scenario.

FWIW I doubt this scenario is so common.

Most of the cases of issues with stats file I've heard of were about a 
database server shared by many applications, separated into databases. 
That's basically the scenario we've been facing with our PostgreSQL 
machines, and the motivation for the split.

Maybe there are many clusters with a single database, containing many 
objects, but I don't remember any recent reports of problems with stats 
files from them. Those pretty much disappeared after 9.3, which is when 
the split happened.

That is not to say we can just design it in a way that will cause OOM 
issues or crashes on such machines ...

regards

--
Tomas Vondra                   http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: [BUGS] BUG #13473: VACUUM FREEZE mistakenly cancel standby sessions
Next
From: Peter Geoghegan
Date:
Subject: Re: 9.5 release notes