Re: unlogged tables
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, marcin mank <marcin.mank@gmail.com>, Andy Colson <andy@squeakycode.net>, pgsql-hackers@postgresql.org
Date: 2010-11-17T18:55:32Z
Lists: pgsql-hackers
On Wed, Nov 17, 2010 at 1:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: >> On 17.11.2010 17:11, Tom Lane wrote: >>> The objection to that was not about performance. It was about how >>> to find out what needs to be fsync'd. > >> I must be missing something: we handle that just fine with normal >> tables, why is it a problem for unlogged tables? > > Hmm ... that's a good point. If we simply treat unlogged tables the > same as regular for checkpointing purposes, don't we end up having > flushed them all correctly during a shutdown checkpoint? I was thinking > that WAL-logging had some influence on that logic, but it doesn't. > > Robert is probably going to object that he wanted to prevent any > fsyncing for unlogged tables, but the discussion over in pgsql-general > is crystal clear that people do NOT want to lose unlogged data over > a clean shutdown and restart. If all it takes to do that is to refrain > from lobotomizing the checkpoint logic for unlogged tables, I say we > should refrain. I think that's absolutely a bad idea. I seriously do not want to have a conversation with someone about why their unlogged tables are exacerbating their checkpoint I/O spikes. I'd be happy to have two modes, though. We should probably revisit the syntax, though. One, it seems that CREATE UNLOGGED TABLE is not as clear as I thought it was. Two, when (not if) we add more durability levels, we don't want to create keywords for all of them. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company