From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, shangzi(dot)x(at)columbia(dot)edu, Pg Docs <pgsql-docs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: relpages in pg_class |
Date: | 2022-08-19 19:16:32 |
Message-ID: | Yv/hkEf1fFDIGl6m@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
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(at)sss(dot)pgh(dot)pa(dot)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(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
Indecision is a decision. Inaction is an action. Mark Batterson
From | Date | Subject | |
---|---|---|---|
Next Message | PG Doc comments form | 2022-08-20 10:39:38 | documentation error |
Previous Message | Peter Geoghegan | 2022-08-19 18:25:52 | Re: relpages in pg_class |