Thread: relpages in pg_class
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/14/catalog-pg-class.html Description: From source code, the relpage is the number of blocks. But, at the document, it is written as Size of the on-disk representation of this table in pages (of size BLCKSZ).
On Fri, Aug 19, 2022 at 04:10:30AM +0000, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/14/catalog-pg-class.html > Description: > > From source code, the relpage is the number of blocks. But, at the document, > it is written as Size of the on-disk representation of this table in pages > (of size BLCKSZ). Well, blocks and pages are the same size, so I don't see the problem. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Indecision is a decision. Inaction is an action. Mark Batterson
On 2022-Aug-19, Bruce Momjian wrote: > On Fri, Aug 19, 2022 at 04:10:30AM +0000, PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > > > Page: https://www.postgresql.org/docs/14/catalog-pg-class.html > > Description: > > > > From source code, the relpage is the number of blocks. But, at the document, > > it is written as Size of the on-disk representation of this table in pages > > (of size BLCKSZ). > > Well, blocks and pages are the same size, so I don't see the problem. If you think about operating system "blocks" rather than Postgres "blocks", I can see how this can be interpreted differently. I'm not sure if this is a good place to make that distinction, though; I mean, if we do, how many other places should we patch similarly? -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "Small aircraft do not crash frequently ... usually only once!" (ponder, http://thedailywtf.com/)
Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > On 2022-Aug-19, Bruce Momjian wrote: >> Well, blocks and pages are the same size, so I don't see the problem. > If you think about operating system "blocks" rather than Postgres > "blocks", I can see how this can be interpreted differently. I'm not > sure if this is a good place to make that distinction, though; I mean, > if we do, how many other places should we patch similarly? Yeah, we use "blocks" and "pages" interchangeably, which is something I don't feel a need to change; but evidently the OP didn't realize that. This is a job for the glossary, perhaps? regards, tom lane
On Fri, Aug 19, 2022 at 9:40 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Yeah, we use "blocks" and "pages" interchangeably, which is something > I don't feel a need to change; but evidently the OP didn't realize that. > This is a job for the glossary, perhaps? I think that they're synonyms that can often (but not always) be used interchangeably. I *think* that this understanding is shared by other people, though I should check. Here goes: To me, "block" emphasizes on-disk/relfilenode storage. Something that exists at a particular physical offset in a particular file (a BlockNumber + relfilenode). On the other hand, the term "page" emphasizes the in-memory format, and the indirection provided by the bufpage.c slotted page format (i.e. line pointer array indirection). This line pointer indirection is really central to lots of important things, including (just for example) our "physiological" approach to WAL logging -- WAL records describe changes in a way that is physical to a block, logical within a page. Most users don't need to care about these distinctions, but hackers might find the nuance of it quite useful. It bleeds into a lot of things, and is quite easy to take for granted -- which might actually cost you. -- Peter Geoghegan
On Fri, Aug 19, 2022 at 11:25:52AM -0700, Peter Geoghegan wrote: > On Fri, Aug 19, 2022 at 9:40 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Yeah, we use "blocks" and "pages" interchangeably, which is something > > I don't feel a need to change; but evidently the OP didn't realize that. > > This is a job for the glossary, perhaps? > > I think that they're synonyms that can often (but not always) be used > interchangeably. I *think* that this understanding is shared by other > people, though I should check. Here goes: > > To me, "block" emphasizes on-disk/relfilenode storage. Something that > exists at a particular physical offset in a particular file (a > BlockNumber + relfilenode). On the other hand, the term "page" > emphasizes the in-memory format, and the indirection provided by the > bufpage.c slotted page format (i.e. line pointer array indirection). Yes, I have heard the block-disk, page-memory explanation before. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Indecision is a decision. Inaction is an action. Mark Batterson
Page and block can be used interchangeably, but the description of relpages in the documentation can be confusing to someone who doesn't care much about the difference between page and block.
When I want to count pages from a table, maybe the keywords I should look for should be "the number of", but the relpages is described by document with "Size of".
-----------------------------------------------
Shangzi Xie
On Sat, Aug 20, 2022 at 3:16 AM Bruce Momjian <bruce@momjian.us> wrote:
On Fri, Aug 19, 2022 at 11:25:52AM -0700, Peter Geoghegan wrote:
> On Fri, Aug 19, 2022 at 9:40 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Yeah, we use "blocks" and "pages" interchangeably, which is something
> > I don't feel a need to change; but evidently the OP didn't realize that.
> > This is a job for the glossary, perhaps?
>
> I think that they're synonyms that can often (but not always) be used
> interchangeably. I *think* that this understanding is shared by other
> people, though I should check. Here goes:
>
> To me, "block" emphasizes on-disk/relfilenode storage. Something that
> exists at a particular physical offset in a particular file (a
> BlockNumber + relfilenode). On the other hand, the term "page"
> emphasizes the in-memory format, and the indirection provided by the
> bufpage.c slotted page format (i.e. line pointer array indirection).
Yes, I have heard the block-disk, page-memory explanation before.
--
Bruce Momjian <bruce@momjian.us> https://urldefense.proofpoint.com/v2/url?u=https-3A__momjian.us&d=DwIBAg&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=Hul745xaxWgD5ax2VcStGxXAXxES8dE1okk4lpHMoao&m=iq1O1WJgFr-Q1WqUjSdWPoPWj7Ui7sDz3fQ5njhfrwdLVNKdZ-fCeSS0TFdJUe-y&s=o-_cOvuvBdiTSvBWdgCX5noK2cE5VZBF-jETQXEA-WE&e=
EDB https://urldefense.proofpoint.com/v2/url?u=https-3A__enterprisedb.com&d=DwIBAg&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=Hul745xaxWgD5ax2VcStGxXAXxES8dE1okk4lpHMoao&m=iq1O1WJgFr-Q1WqUjSdWPoPWj7Ui7sDz3fQ5njhfrwdLVNKdZ-fCeSS0TFdJUe-y&s=e2Z4mi_VN2ktgB7rh3Y7N4KhPdeTi-4knCQ7yirZK1E&e=
Indecision is a decision. Inaction is an action. Mark Batterson