Thread

Re: [HACKERS] 6.5 TODO list

Ole Gjerde <gjerde@icebox.org> — 1999-05-11T20:11:40Z

On Tue, 11 May 1999, Tom Lane wrote:
> I think there are two known issues right now: the VACUUM one and
> something about DROP TABLE neglecting to delete the additional files
> for a multi-segment table.  To my mind the VACUUM problem is a "must
> fix" because you can't really live without VACUUM, especially not on
> a huge database.  The DROP problem is less severe since you could
> clean up by hand if necessary (not that it shouldn't get fixed of
> course, but we have more critical issues to deal with for 6.5).

I have been looking at the code for dropping the table.  The code in
mdunlink() seems to be correct, and *should* work.  Of course it don't, so
I'll do some more testing tonight and hopefully I can figure out why it
doesn't work.

As far as the VACUUM problem, I still haven't seen that.  I have a couple
~3GB tables, with one growing to 5-6GB in the next month or so.  VACUUM
runs just fine on both.

I just got to thinking, what about indexes > 2GB?  With my 3GB table one
of the index is 540MB.  Both with growth I might get there.  Does that
work and does it use RELSEG_SIZE?
I would guess that the same function(mdunlink, mdcreate, etc) is called
for all DROPs and CREATEs(through DestroyStmt, CreateStmt)?  I don't
understand postgres good enough to answer that for sure(but it does make
sense).

Ole Gjerde