| 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: | Whole Thread | Raw Message | 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 |