Thread: smgr.c and smgrtype.c
Hello all, I'm trying to modify the storage manager now. I found a number of smgrs are stored separately in the storage manager module (NSmgr in smgr.c and NStorageManagers in smgrtype.c), and names of storage managers are stored in smgrtype.c. Are there any reason for this? I think they shold be stored in smgr.c and and interfaces to get a name of smgr or a number of smgrs should be provided. And the smgrid struct (in smgrtype.c) is (still) used? My patch is available here: http://snaga.org/pgsql/patches/smgr.patch Any comments? -- NAGAYASU Satoshi <nagayasus@nttdata.co.jp> OpenSource Development Center, NTT DATA Corp. http://www.nttdata.co.jp/
Satoshi Nagayasu <nagayasus@nttdata.co.jp> writes:
> I'm trying to modify the storage manager now.
Um ... why?
There is no doubt that the current smgr interface leaves a lot to be
desired, but the reason that it's in such sad shape is that there is
absolutely no modern-day use for an API at that particular level of
abstraction. The stuff that the Berkeley boys and girls envisioned
doing here has all migrated down into the kernel, if not clear down
into the hardware (think RAID controller). Most of the stuff that
people would now like to have an API separation for is at much higher
levels of abstraction. For example, the smgr API doesn't even know what
a tuple or an index *is*, much less have the potential to modify lookup
or locking or replication semantics.
If anyone had wanted to add a new storage manager in the last fifteen
years, we'd doubtless have tried to clean this up some, but no one has
and I'm not really expecting anyone to try in the next fifteen...
regards, tom lane
>>I'm trying to modify the storage manager now. > > Um ... why? Because I want to add my new storage manager. It is not just for (single) magnetic disk. > If anyone had wanted to add a new storage manager in the last fifteen > years, we'd doubtless have tried to clean this up some, but no one has > and I'm not really expecting anyone to try in the next fifteen... I guess clean separation and APIs are necessary for now. If one need to modify/extend a storage manager for better performance, clean design and APIs are essentials. For my purpose, I'm thinking about a pluggable storage manager mechanism using dynamic loading, because I want to develop my smgr independently from main codebase... -- NAGAYASU Satoshi <nagayasus@nttdata.co.jp> OpenSource Development Center, NTT DATA Corp. http://www.nttdata.co.jp/