Skip site navigation (1) Skip section navigation (2)

Re: I/O on select count(*)

From: Decibel! <decibel(at)decibel(dot)org>
To: Greg Smith <gsmith(at)gregsmith(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: I/O on select count(*)
Date: 2008-05-24 19:15:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On May 18, 2008, at 1:28 AM, Greg Smith wrote:
> I just collected all the good internals information included in  
> this thread and popped it onto 
> Hint_Bits where I'll continue to hack away at the text until it's  
> readable.  Thanks to everyone who answered my questions here,  
> that's good progress toward clearing up a very underdocumented area.
> I note a couple of potential TODO items not on the official list  
> yet that came up during this discussion:
> -Smooth latency spikes when switching commit log pages by  
> preallocating cleared pages before they are needed
> -Improve bulk loading by setting "frozen" hint bits for tuple  
> inserts which occur within the same database transaction as the  
> creation of the table into which they're being inserted
> Did I miss anything?  I think everything brought up falls either  
> into one of those two or the existing "Consider having the  
> background writer update the transaction status hint bits..." TODO.

Blah, sorry for the double-post, but I just remembered a few things...

Did we completely kill the idea of the bg_writer *or some other  
background process* being responsible for setting all hint-bits on  
dirty pages before they're written out?

Also, Simon and Tom had an idea at PGCon: Don't set hint-bits in the  
back-end if the page isn't already dirty. We'd likely need some  
heuristics on this... based on Luke's comments about improved CLOG  
caching maybe we want to set the bits anyway if the tuples without  
them set are from old transactions (idea being that pulling those  
CLOG pages would be pretty expensive). Or better yet; if we have to  
read a CLOG page off disk, set the bits.

This could still potentially be a big disadvantage for data  
warehouses; though perhaps the way to fix that is recommend a  
backgrounded vacuum after data load.
Decibel!, aka Jim C. Nasby, Database Architect  decibel(at)decibel(dot)org
Give your computer some brain candy! Team #1828

In response to


pgsql-performance by date

Next:From: Jeffrey BakerDate: 2008-05-24 20:39:15
Subject: Re: Quad Xeon or Quad Opteron?
Previous:From: Decibel!Date: 2008-05-24 19:06:56
Subject: Re: I/O on select count(*)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group