pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Heikki Linnakangas <heikki@enterprisedb.com>
To: Matthew Wakeling <matthew@flymine.org>
Cc: pgsql-performance@postgresql.org
Subject: Re: I/O on select count(*)
Date: Thu, 15 May 2008 13:52:31 +0100
Message-ID: <482C320F.9070908@enterprisedb.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0805151245360.16756@aragorn.flymine.org>
References: <920841.71690.qm@web44808.mail.sp1.yahoo.com>
	<482B1D5F.EE98.0025.0@wicourts.gov>
	<Pine.GSO.4.64.0805142133250.27290@westnet.com>
	<20080515020553.GN9838@alvh.no-ip.org>
	<Pine.LNX.4.64.0805151245360.16756@aragorn.flymine.org>

Matthew Wakeling wrote:
> Is it really safe to update the hint bits in place? If there is a power 
> cut in the middle of writing a block, is there a guarantee from the disc 
> that the block will never be garbled?

Don't know, to be honest. We've never seen any reports of corrupted data 
that would suggest such a problem, but it doesn't seem impossible to me 
that some exotic storage system might do that.

> Is there a way to make a shortcut and have the hint bits written the 
> first time the data is written to the table? One piece of obvious 
> low-hanging fruit would be to enhance step five above, so that the 
> bgwriter or checkpoint that writes the data to the database table checks 
> the pg_clog and writes the correct hint bits.

Yep, that's an idea that's been suggested before. In fact, I seem to 
remember a patch to do just that. Don't remember what happened to it,

> In fact, if the tuple's 
> creating transaction has aborted, then the tuple can be vacuumed right 
> there and then before it is even written. 

Not if you have any indexes on the table. To vacuum, you'll have to scan 
all indexes to remove pointers to the tuple.

> However, this idea does not deal well with bulk data loads, where the 
> data is checkpointed before transaction is committed or aborted.

Yep, that's the killer :-(.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com



view thread (54+ messages)  latest in thread

Message-ID: <482C320F.9070908@enterprisedb.com>
Permalink:  ../482C320F.9070908@enterprisedb.com/
Also on:    postgresql.org/message-id/482C320F.9070908@enterprisedb.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: heikki@enterprisedb.com, matthew@flymine.org
  Subject: Re: I/O on select count(*)
  In-Reply-To: <482C320F.9070908@enterprisedb.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox