Alice Lottini <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
defineblock = unit of I/O (between Postgres and the kernel, that is)page = unit within which space allocation is done
fortuples
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
