Re: Index Scans become Seq Scans after VACUUM ANALYSE

Поиск
Список
Период
Сортировка
От Curt Sampson
Тема Re: Index Scans become Seq Scans after VACUUM ANALYSE
Дата
Msg-id Pine.NEB.4.43.0206221731130.1091-100000@angelic.cynic.net
обсуждение исходный текст
Ответ на Re: Index Scans become Seq Scans after VACUUM ANALYSE  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Marc G. Fournier"
Дата:
Сообщение: Re: test 2, first failed ...
Следующее
От: "Rod Taylor"
Дата:
Сообщение: pg_dump and ALTER TABLE / ADD FOREIGN KEY