> -----Original Message-----
> From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> Sent: Tuesday, October 19, 1999 6:45 PM
> To: Tom Lane
> Cc: pgsql-hackers@postgreSQL.org
> Subject: RE: [HACKERS] mdnblocks is an amazing time sink in huge
> relations
>
>
> >
> > "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
>
> [snip]
>
> >
> > > Deletion is necessary only not to consume disk space.
> > >
> > > For example vacuum could remove not deleted files.
> >
> > Hmm ... interesting idea ... but I can hear the complaints
> > from users already...
> >
>
> My idea is only an analogy of PostgreSQL's simple recovery
> mechanism of tuples.
>
> And my main point is
> "delete fails after commit" doesn't harm the database
> except that not deleted files consume disk space.
>
> Of cource,it's preferable to delete relation files immediately
> after(or just when) commit.
> Useless files are visible though useless tuples are invisible.
>
Anyway I don't need "DROP TABLE inside transactions" now
and my idea is originally for that issue.
After a thought,I propose the following solution.
1. mdcreate() couldn't create existent relation files. If the existent file is of length zero,we would overwrite
thefile.(seems the comment in md.c says so but the code doesn't do so). If the file is an Index relation file,we
wouldoverwrite the file.
2. mdunlink() couldn't unlink non-existent relation files. mdunlink() doesn't call elog(ERROR) even if the file
doesn'texist,though I couldn't find where to change now. mdopen() doesn't call elog(ERROR) even if the file
doesn'texist and leaves the relation as CLOSED.
Comments ?
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
