Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] DROP TABLE inside a transaction block

From: Michael Alan Dorman <mdorman(at)debian(dot)org>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
Date: 2000-03-08 14:04:27
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.


In response to

pgsql-hackers by date

Next:From: Thomas LockhartDate: 2000-03-08 14:06:35
Subject: Re: [HACKERS] library policy question
Previous:From: Mark HollomonDate: 2000-03-08 13:05:20
Subject: Re: [HACKERS] DROP TABLE inside a transaction block

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group