Robert Haas <robertmhaas@gmail.com> wrote:
> So, what is the roadmap for getting this done? It seems like to get
> rid of VFI completely, we would need to implement something like what
> Tom described here:
>
> http://archives.postgresql.org/pgsql-hackers/2009-09/msg00249.php
>
> I'm not sure whether the current patch is a good intermediate step
> towards that ultimate goal, or whether events have overtaken it.
I think the most desirable roadmap is: 1. Enable CLUSTER to non-critical system catalogs. 2. Also enable CLUSTER
andREINDEX to critical system catalogs. 3. Remove VFI and re-implement VACUUM FULL with CLUSTER-based approach.
Itshould be also optimized as Simon's suggestion.
My patch was intended to do 3, but we should not skip 1 and 2. In the roadmap,
we don't have two versions of VACUUM FULL (INPLACE and REWRITE) at a time.
I think we can do 1 immediately. The comment in cluster says "might work",
and I also think so. CLUSTERable toast tables are obviously useful. /* * Disallow clustering system relations.
Thiswill definitely NOT work * for shared relations (we have no way to update pg_class rows in other *
databases),nor for nailed-in-cache relations (the relfilenode values * for those are hardwired, see relcache.c). It
mightwork for other * system relations, but I ain't gonna risk it. */
For 2, we need some kinds of "relfilenode mapper" for shared relations
and critical local tables (pg_class, pg_attribute, pg_proc, and pg_type).
I'm thinking that we only store "virtual" relfilenodes for them in pg_class
and remember the actual relfilenodes in shared memory. For example,
smgropen(1248:pg_database) is redirected to smgropen(mapper[1248]).
Since we cannot touch pg_class in non-login databases, we need to avoid
updating pg_class when we assign new relfilenodes for shared relations.
We also need to store the nodes in additional flat file. There might be
another approach to store them in control file for shared relation
(ControlFileData.shared_relfilenode_mapper as Oid[]), or pg_database
for local tables (pg_database.datclsssnode, datprocnode etc.)
What approach would be better?
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center
