=?iso-8859-1?q?Alice=20Lottini?= <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html