From: | Shawn Debnath <sdn(at)amazon(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Retronym: s/magnetic disk/main data/ |
Date: | 2019-04-04 18:52:52 |
Message-ID: | 20190404185251.GA47724@f01898859afd.ant.amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Apr 04, 2019 at 03:09:15PM +0900, Michael Paquier wrote:
> On Thu, Apr 04, 2019 at 05:49:36PM +1300, Thomas Munro wrote:
> > I propose that in v13 we redefine "MD" (from md.c) to mean "main data"
> > (instead of "magnetic disk"). That's the standard storage layout for
> > typical table and index AMs. As opposed to the proposed undo and SLRU
> > SMGRs that provide layouts specialised for different life cycles.
>
> If there is a much better name, I would have no objections with just
> renaming the file md.c instead into something that has a better
> meaning than "main data", which does not seem to be a name going to
> the actual point...
+1 on changing this to be something other than magnetic disk. I would
vote for renaming it to relation to be in parity with SMgrRelation.
Relation storage manager also captures the responsibilities accurately
and fits with future undo and 'slru' (?) storage managers for example.
--
Shawn Debnath
Amazon Web Services (AWS)
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2019-04-04 19:01:26 | Re: query logging of prepared statements |
Previous Message | Floris Van Nee | 2019-04-04 18:33:55 | Re: speeding up planning with partitions |