On 28 July 2012 17:15, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
