Re: Adding probes for smgr

Peter Geoghegan <peter(at)2ndquadrant(dot)com> writes:
> On 28 July 2012 17:15, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> IMV smgr is pretty vestigial. I wouldn't recommend loading more
>> functionality onto that layer, because it's as likely as not that
>> we'll just get rid of it someday.

> Agreed. I recently found myself reading a paper written by Stonebraker
> back in the Berkeley days:
> http://dislab2.hufs.ac.kr/dislab/seminar/2007/ERL-M87-06.pdf
> This paper appears to have been published in about 1988, and it shows.
> It's fairly obvious from reading the opening paragraph that the
> original rationale for the design of the storage manager doesn't hold
> these days. Of course, it's also obvious from reading the code, since
> for example there is only one storage manager module.

Yeah. There were actually two storage managers in what we inherited
from Berkeley, but we soon got rid of the other one as being useless.
(IIRC it was meant for magnetic-core memory ... anybody seen any of
that lately?)

I think basically what happened since then is that the functionality
Stonebraker et al imagined as being in per-storage-manager code all
migrated into the kernel device drivers, or even down into the hardware
itself. (SSDs are *way* smarter than the average '80s storage device,
and even those were an order of magnitude smarter than what they'd been
ten years previously. I used to do device drivers back in the 80's...)
There's no longer any good reason to have anything but md.c, which isn't
so much a "magnetic disk" interface as an "interface to something that
has a Unix block device driver".

> This state of affairs sort of reminds me of mcxt.c . The struct
> MemoryContextData is described as an "abstract type" that can have
> multiple implementations, despite the fact that since 2000 (and
> perhaps earlier), the underlying type is invariably AllocSetContext. I
> never investigated if that indirection still needs to exist, but I
> suspect that it too is a candidate for refactoring. Do you agree?

Meh. Having invented the MemoryContext interface, I am probably not
the best-qualified person to evaluate it objectively. The original
thought was that we might have (a) a context type that could allocate
storage in shared memory, and/or (b) a context type that could provide
better allocation speed at a loss of storage efficiency (eg, lose the
ability to pfree individual chunks). Case (a) has never become
practical given the inability of SysV-style shared memory to expand at
all. I don't know if that might change when/if we switch to some other
shmem API. The idea of a different allocation strategy for some usages
still seems like something we'll want to do someday, though.

regards, tom lane