On Fri, Aug 20, 2010 at 3:43 AM, Robert Haas <robertmh...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers