On Wed, Nov 17, 2010 at 11:00 AM, Greg Stark <gsstark@mit.edu> wrote:
> On Wed, Nov 17, 2010 at 3:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>>> fsync()ing the file at shutdown doesn't seem too bad to me from
>>> performance point of view, we tolerate that for all other tables. And
>>> you can always truncate the table yourself before shutdown.
>>
>> The objection to that was not about performance. It was about how
>> to find out what needs to be fsync'd.
>
> Just a crazy brainstorming thought, but....
>
> If this is a clean shutdown then all the non-unlogged tables have been
> checkpointed so they should have no dirty pages in them anyways. So we
> could just fsync everything.
Hmm, that reminds me: checkpoints should really skip writing buffers
belonging to unlogged relations altogether; and any fsync against an
unlogged relation should be skipped. I need to go take a look at
what's required to make that happen, either as part of this patch or
as a follow-on commit.
It might be interesting to have a kind of semi-unlogged table where we
write a special xlog record for the first access after each checkpoint
but otherwise don't xlog. On redo, we truncate the tables mentioned,
but not any others, since they're presumably OK. But that's not what
I'm trying to design here. I'm trying optimize it for the case where
you DON'T care about durability and you just want it to be as fast as
possible.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company