Re: Index Scans become Seq Scans after VACUUM ANALYSE - Mailing list pgsql-hackers

From Curt Sampson
Subject Re: Index Scans become Seq Scans after VACUUM ANALYSE
Date
Msg-id Pine.NEB.4.43.0206221731130.1091-100000@angelic.cynic.net
Whole thread Raw
In response to Re: Index Scans become Seq Scans after VACUUM ANALYSE  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, 21 Jun 2002, Tom Lane wrote:

> Curt Sampson <cjs@cynic.net> writes:
> > And now you know which parts of your page got written, and which
> > parts didn't.
>
> Yes ... and what do you *do* about it?

Ok. Here's the extract from _Inside Microsoft SQL Server 7.0_, page 207:
   torn page detection   When TRUE, this option causes a bit to beflipped for each 512-byte sector in a database page
(8KB)whenever the page is written to disk.  This option allowsSQL Server to detect incomplete I/O operations caused
bypowerfailures or other system outages. If a bit is in thewrong state when the page is later read by SQL Server,
thismeansthe page was written incorrectly; a torn page hasbeen detected. Although SQL Server database pages are 8KB,
disksperform I/O operations using 512-byte sectors.Therefore, 16 sectors are written per database page.  Atorn page can
occurif the system crashes (for example,because of power failure) between the time the operatingsystem writes the first
512-bytesector to disk and thecompletion of the 8-KB I/O operation.  If the first sectorof a database page is
successfullywritten before the crash,it will appear that the database page on disk was updated,although it might not
havesucceeded. Using battery-backeddisk caches can ensure that data is [sic] successfullywritten to disk or not written
atall. In this case, don'tset torn page detection to TRUE, as it isn't needed. If atorn page is detected, the database
willneed to be restoredfrom backup because it will be physically inconsistent.
 

As I understand it, this is not a problem for postgres becuase the
entire page is written to the log. So postgres is safe, but quite
inefficient. (It would be much more efficient to write just the
changed tuple, or even just the changed values within the tuple,
to the log.)

Adding these torn bits would allow posgres at least to write to
the log just the 512-byte sectors that have changed, rather than
the entire 8 KB page.

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org   Don't you know, in this new Dark Age, we're
alllight.  --XTC
 



pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: test 2, first failed ...
Next
From: "Rod Taylor"
Date:
Subject: pg_dump and ALTER TABLE / ADD FOREIGN KEY