Re: small smgrcreate cleanup patch

On Fri, Aug 20, 2010 at 3:43 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> A related, interesting question is whether there's any purpose to the
> smgr layer at all.  Would we accept a patch that implemented an
> alternative smgr layer, perhaps on a per-tablespace basis?

I definitely want to keep it.

I think we could usefully do an application-level raid implementation.
It would be useful for people running on machines where they don't
have administrative access on the machine. In particular I'm picturing
shared cluster machines that run other jobs and can't be reconfigured
specifically for the database. Adding per-tablespace behaviour would
make the argument a lot stronger too since it's not so easy to set up
different stripe sizes per table if you're using OS level raid.

I also have various crazy plans to experiment with network-based
storage and had intended to use smgr to do so. At google we have a
bunch of different storage technologies and they're all
application-level network services. You can always implement a fuse
module that calls back up to a daemon which acts as the client but
that doesn't make me feel any happier about it.

And I know EDB has their infinicache thing using memcached -- I don't
recall if it uses the smgr layer but it would certainly be a natural
place to hook it in.

I guess my point here is that regardless of whether we plan on
accepting any such patches in core it's a very handy hook for third
parties to extend postgres with. It would be nice if we had some of
those modules in contrib to keep us honest with the api but even as it
stands I think it's useful.

--
greg