Re: [GENERAL] Autovacuum Improvements - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: [GENERAL] Autovacuum Improvements
Date
Msg-id 20070122231102.GS64372@nasby.net
Whole thread Raw
In response to Re: [GENERAL] Autovacuum Improvements  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
Responses Re: [GENERAL] Autovacuum Improvements  (Kenneth Marshall <ktm@it.is.rice.edu>)
Re: [GENERAL] Autovacuum Improvements  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Mon, Jan 22, 2007 at 12:17:39PM -0800, Ron Mayer wrote:
> Gregory Stark wrote:
> > 
> > Actually no. A while back I did experiments to see how fast reading a file
> > sequentially was compared to reading the same file sequentially but skipping
> > x% of the blocks randomly. The results were surprising (to me) and depressing.
> > The breakeven point was about 7%. [...]
> > 
> > The theory online was that as long as you're reading one page from each disk
> > track you're going to pay the same seek overhead as reading the entire track.
> 
> Could one take advantage of this observation in designing the DSM?
> 
> Instead of a separate bit representing every page, having each bit
> represent 20 or so pages might be a more useful unit.  It sounds
> like the time spent reading would be similar; while the bitmap
> would be significantly smaller.

If we extended relations by more than one page at a time we'd probably
have a better shot at the blocks on disk being contiguous and all read
at the same time by the OS.
-- 
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Piggybacking vacuum I/O
Next
From: "Jim C. Nasby"
Date:
Subject: Re: pg_dump ANALYZE statements