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

From Jeff Janes
Subject Re: pg_stat_*_columns?
Date
Msg-id CAMkU=1xaWRytpEPVGcDgYmedVvQA+DiEmp31U8CUW9KLw20rJA@mail.gmail.com
Whole thread Raw
In response to Re: pg_stat_*_columns?  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: pg_stat_*_columns?  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
On Mon, Jun 15, 2015 at 7:47 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
On 6/8/15 3:26 PM, Joel Jacobson wrote:
So I've heard from Magnus Hagander today IRL at our Stockholm PostgreSQL
User Group meeting where we discussed this idea. He told me the overhead
in the statistics collector is mainly when reading from it, not that
much when writing to it.

I've heard enough stories of people moving the stats files to faster storage that I'm not sure how true that really is...


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?

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.

Perhaps the problem was related to that.

Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)
Next
From: Peter Geoghegan
Date:
Subject: Re: UPSERT on partition