On Mon, May 21, 2012 at 3:15 PM, Stephen Frost <sfr...@snowman.net> wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> The FSM and VM are small enough >> that interleaving them with the actual data probably wouldn't slow >> down seq scans materially. > > Wouldn't that end up potentially causing lots of random i/o if you need > to look at many parts of the FSM or VM..?
I doubt it. They probably stay in core anyway. > Also, wouldn't having it at the start of the heap reduce the changes > needed to the SM? Along with make such things easier to find > themselves, when talking about forensics? The metapage, surely yes. If we wanted to fold the FSM and VM into the main fork in their entirety, probably not. But I don't have much desire to do that. I think it's fine for a BIG relation to eat a couple of inodes. I just don't want a little one to do that. > Of course, the real challenge here is dealing with such an on-disk > format change... If we were starting from scratch, I doubt there would > be much resistance, but figuring out how to do this and still support > pg_upgrade could be quite ugly. That does seem to be the ten million dollar question, but already we've batted around a few solutions on this thread, so I suspect we'll find a way to make it work. I think my next step is going to be to spend some more time studying what the various index AMs already have in terms of metapages. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers