Re: [HACKERS] DROP TABLE inside a transaction block

pgman(at)candle(dot)pha(dot)pa(dot)us (Bruce Momjian) writes:
> I have cursed Ingres every time I needed to look at the Ingres data
> directory to find out which tables match which files. Even a lookup
> file is a pain. Right now, I can do ls -l to see which tables are
> taking disk space.
>
> Considering the number of times administrators have to do this, it is a
> pain. It is only lazy database internals programmers that would advance
> an oid-only file name concept. FYI, Informix SE uses this the
> tablename_oid concept in their implementation.
>
> Keeping that flat file in sync with the database will be a royal pain.
> Imagine the concurrency problems keeping it up to date.

I'm just a lurker here, and not familiar with postgres internals, so
this suggestion could easily be so ignorant that it's simply not worth
it to even respond.

Caveats aside, it occurs to me that a possible compromise might be to
name tables files by OID, but put them in directories that are named
for the tables themselves.

Bruce has to use du -s rather than ls -l, but he can still achieve the
same end (measuring space used by particular tables), while allowing
the tables to be named by OID, which means that we could get the
benefits that accrue from that.

This actually occured to me when the whole "tablespace" discussion
came up a couple of months ago---by using a different directory for
each table, it would suddenly become very easy to split up a database
across spindles with what would seem to be at least adequate control.

Again, I am sufficiently ignorant of postgres internals---I just read
the list, I haven't really looked at the code---that this is probably
utterly untenable.

Mike.