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

From Tomas Vondra
Subject Re: pg_stat_*_columns?
Date
Msg-id 558B400D.8070900@2ndquadrant.com
Whole thread Raw
In response to Re: pg_stat_*_columns?  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: pg_stat_*_columns?  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers

On 06/24/2015 07:54 PM, Jeff Janes 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.


> When I was testing the stat file split patch, one thing I noticed is
> that on the ext4 file system, when you atomically replace a file by
> renaming a file over the top of an existing file name, it will
> automatically fsync the file being renamed. This is exactly what we
> don't want in the case of the temp stats files.  But there seems to be
> no way to circumvent it, other than unlinking the target file before the
> rename (which of course defeats the point of atomic replacement), or
> moving to a different filesystem for the stats files.

Interesting. I don't think unlinking is a good idea - my understanding 
is that we do it this way because rename is supposed to be atomic or 
something like that. I don't know whether addressing this filesystem 
feature is worth it, or if pgstat.c is the right place to do that.

--
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: less log level for success dynamic background workers for 9.5
Next
From: Amit Langote
Date:
Subject: Re: UPSERT on partition