Re: heap metapages
| От | Robert Haas |
|---|---|
| Тема | Re: heap metapages |
| Дата | |
| Msg-id | CA+TgmoYa2ycxmhT-QFpaZ2hGit7TpgS11_9gxz9Hvm5xkf=8mg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: heap metapages (Stephen Frost <sfrost@snowman.net>) |
| Список | pgsql-hackers |
On Mon, May 21, 2012 at 3:15 PM, Stephen Frost <sfrost@snowman.net> wrote: > * Robert Haas (robertmhaas@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
В списке pgsql-hackers по дате отправления: