On Thu, Feb 28, 2019 at 11:06 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > It's certainly possible/likely that we're going to end up needing to > widen buffer tags to represent the smgr explicitly, because some use > cases are going to need a real database spec, some are going to need > a real tablespace spec, and some might need both. Maybe we should > just bite that bullet.
Well, Andres will probably complain about that. He thinks, IIUC, that the buffer tags are too wide already and that it's significantly hurting performance on very very common operations - like buffer lookups. I haven't verified that myself, but I tend to think he knows what he's talking about. Anyway, given that your argument started off from the premise that we had to have a pg_database row, I think we'd better look a little harder at whether that premise is correct before getting too excited here. As I said in my earlier reply, I think that we probably don't need to have a pg_database row given that we wrap around to FirstNormalObjectId; any value we hard-code would be less than that. If there are other reasons why we'd need that, it might be useful to hear about them. However, all we really need to decide on this thread is whether we need 'smgr' exposed as an SQL type. And I can't see why we need that no matter how all of the rest of this turns out. Nobody is currently proposing to give users a choice of smgrs, just to use them for internal stuff. Even if that changed later, it doesn't necessarily mean we'd add back an SQL type, or that if we did it would look like the one we have today. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
