Andres Freund wrote: > 2) Replace relation forks, with the exception of the init fork which is > special anyway, with separate relfilenodes. Stored in seperate > columns in pg_class.
Different AMs have different fork needs; for heaps you want one main fork, one VM, one fsm. But for indexes, the VM fork is not necessary, and some AMs might want different ones. For instance, GIN would benefit from having separate forks to store the internal indexes, and BRIN would benefit from a separate fork for the revmap. What I'm saying is that I'm not sure it's okay to store the forks in pg_class columns; instead perhaps we should have a separate catalog on which each relation can have many forks, or perhaps have the pg_class entry store an array (ick). Or perhaps rather than "relvmfork" (the pg_class column for the relfilenode for the VM fork) we could store relfilenode1, relfilenode2 where the value for each N fork is AM-specific. (so for heaps 1 is main, 2 is FSM, 3 is VM; for BRIN 1 is main, 2 is revmap; and so forth). FWIW the whole idea seems reasonable to me. I worry about concurrent traffic into the pg_relfilenode shared table -- if temp table creation is common across many databases, is it going to become a contention point? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
