Hi,
we'd like to know how disk pages map to disk blocks.
In particular, looking at the code it seems that one
page can be built on several disk blocks while in the
first lines of bufpage.h it is said that "a postgres
disk page is an abstraction layered on top of *a*
postgres disk block".
As a matter of fact, it looks quite reasonable to have
more than a block per page.
We've also found out that a postgres buffer contains
exactly one disk block, but we'd like to understand
how pages, blocks and buffers relate to each other.

Thank you very much for your help!
regards, alice and lorena 


______________________________________________________________________
Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonino
http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.html

Thu, 6 Feb 2003 17:30:01 +0100 (CET)
=?iso-8859-1?q?Alice=20Lottini?= <alice_lottini@yahoo.it>
disk pages, buffers and blocks
=?iso-8859-1?q?Alice=20Lottini?= <alice_lottini@yahoo.it> writes:
> we'd like to know how disk pages map to disk blocks.

There is no real distinction between the concepts in Postgres ---
"page" and "block" are interchangeable terms, and a buffer always
holds exactly one of either.

The number of filesystem blocks or physical disk sectors needed to hold
a Postgres page is a different question, of course.  Postgres does not
actually care about that, at least not directly.  (But for efficiency
reasons you want a Postgres page to be a multiple of the disk sector
size and filesystem block size, and probably not a very large multiple.)
Not sure if that's relevant to your confusion or not.

> first lines of bufpage.h it is said that "a postgres
> disk page is an abstraction layered on top of *a*
> postgres disk block".

I think that was written about fifteen years back by a Comp Sci grad
student overinfatuated with the notion of abstraction ;-).  It is true
that the storage manager pushes blocks around without caring much what
is in them, but I see no real value in drawing a distinction between
a block and a page.  If you were to make such a distinction you might
define
	block = unit of I/O (between Postgres and the kernel, that is)
	page = unit within which space allocation is done for tuples

But it doesn't make any sense to use a page size that is different from
the unit of I/O.  Certainly there's no point in making it smaller
(that would just restrict the size of tuples, to no purpose) and if
you make it bigger then you have to worry about tuples that have only
partially been written out.

Also, the present design for WAL *requires* block == page in this sense,
because the LSN timestamp in each page header is meant to indicate
whether the page is up-to-date on disk, and so the unit of I/O has to be
a page.

			regards, tom lane

Thu, 06 Feb 2003 12:24:39 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: disk pages, buffers and blocks 