From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> |
Cc: | Joel Jacobson <joel(at)trustly(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: pg_stat_*_columns? |
Date: | 2015-06-24 17:54:33 |
Message-ID: | CAMkU=1xaWRytpEPVGcDgYmedVvQA+DiEmp31U8CUW9KLw20rJA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 15, 2015 at 7:47 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2015-06-24 18:02:36 | Re: UPSERT on partition |
Previous Message | Andres Freund | 2015-06-24 17:41:27 | Re: Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?) |