From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: OK, OK, Hiroshi's right: use a seperately-generated filename |
Date: | 2000-06-17 16:24:56 |
Message-ID: | 18936.961259096@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
>> One thing we'd have to work out is that the critical system tables
>> (eg, pg_class itself, as well as its indexes) would have to have
>> predictable physical names.
> The only limitation of the relation filename is the uniqueness.
> So it doesn't introduce any inconsistency that system tables
> have fixed name.
> As for system relations it wouldn't be so bad because CLUSTER/
> ALTER TABLE DROP COLUMN ... would be unnecessary(maybe).
> But as for system indexes,it is preferable that VACUUM/REINDEX
> could rebuild them safely. System indexes never shrink currently.
Right, it's the index-shrinking business that has me worried.
Most of the other reasons for swapping in a new file don't apply
to system tables, but that one does.
One possibility is to say that system *tables* can't be reversioned
(at least not the critical ones) but system *indexes* can be.
Then we'd have to use your ignore-system-indexes stuff during backend
startup, until we'd found out where the indexes are. Might be too big
a time penalty however... not sure. Shared cache inval of a system
index could be a little tricky too; I don't think the catcache routines
are prepared to fall back to non-index scan are they?
On the whole it might be better to cheat by using a side data structure
like the pg_internal.init file, that a backend could consult to find out
where the indexes are now.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kaare Rasmussen | 2000-06-17 16:32:06 | RE: Big 7.1 open items |
Previous Message | Tom Lane | 2000-06-17 16:11:18 | Re: Big 7.1 open items |