RE: [HACKERS] mdnblocks is an amazing time sink in huge relations

> -----Original Message-----
> From: Hiroshi Inoue [mailto:Inoue(at)tpf(dot)co(dot)jp]
> Sent: Tuesday, October 19, 1999 6:45 PM
> To: Tom Lane
> Cc: pgsql-hackers(at)postgreSQL(dot)org
> Subject: RE: [HACKERS] mdnblocks is an amazing time sink in huge
> relations
>
>
> >
> > "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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
the file.(seems the comment in md.c says so but the
code doesn't do so).
If the file is an Index relation file,we would overwrite
the file.

2. mdunlink() couldn't unlink non-existent relation files.
mdunlink() doesn't call elog(ERROR) even if the file
doesn't exist,though I couldn't find where to change
now.
mdopen() doesn't call elog(ERROR) even if the file
doesn't exist and leaves the relation as CLOSED.

Comments ?

Regards.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp