Gregory Stark wrote:
"Tom Lane" <[EMAIL PROTECTED]> writes:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
My original thought was to have a separate RelFileNode for each of the
maps. That would require no smgr or xlog changes, and not very many
changes in the buffer manager, though I guess you'd more catalog
changes. You had doubts about that on the previous thread
(http://archives.postgresql.org/pgsql-hackers/2007-11/msg00204.php), but
the "map forks" idea certainly seems much more invasive than that.
The main problems with that are (a) the need to expose every type of map
in pg_class and (b) the need to pass all those relfilenode numbers down
to pretty low levels of the system. The nice thing about the fork idea
is that you don't need any added info to uniquely identify what relation
you're working on. The fork numbers would be hard-wired into whatever
code needed to know about particular forks. (Of course, these same
advantages apply to using special space in an existing file. I'm
just suggesting that we can keep these advantages without buying into
the restrictions that special space would have.)
One advantage of using separate relfilenodes would be that if we need to
regenerate a map we could do it in a new relfilenode and swap it in like we do
with heap rewrites.
Why can't you just do that with a different extension and file rename?
You'd need an exclusive lock while swapping in the new map, but you need
that anyway, IIRC, and this way you don't even need a catalog change.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
