Re: pg_stat_*_columns?

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: pg_stat_*_columns?
Дата
Msg-id 558DEB42.9070307@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: pg_stat_*_columns?  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список 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 по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: [BUGS] BUG #13473: VACUUM FREEZE mistakenly cancel standby sessions
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: 9.5 release notes