On 28 July 2012 17:15, Tom Lane <tgl@sss.pgh.pa.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.
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?
Incidentally, you might consider refreshing these remarks in the smgr README:
"In Berkeley Postgres each relation was tagged with the ID of the
storage manager to use for it. This is gone. It would be more
reasonable to associate storage managers with tablespaces (a feature
not present as this text is being written, but one likely to emerge
soon)."
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
