Re: [HACKERS] DROP TABLE inside a transaction block - Mailing list pgsql-hackers

From Michael Alan Dorman
Subject Re: [HACKERS] DROP TABLE inside a transaction block
Date
Msg-id 87hfehzhg4.fsf@kate.private.net
Whole thread Raw
In response to Re: [HACKERS] DROP TABLE inside a transaction block  (Lamar Owen <lamar.owen@wgcr.org>)
List pgsql-hackers
pgman@candle.pha.pa.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.


pgsql-hackers by date:

Previous
From: Ed Loehr
Date:
Subject: [HACKERS] Transaction abortions & recovery handling
Next
From: Thomas Lockhart
Date:
Subject: Re: [HACKERS] library policy question