> Christopher Masto <chris@netmonger.net> writes:
> > Anyway, I guess my point is that there is some incentive here for
> > having a postgres that is completely non-iffy when it comes to >2GB
> > databases. Shortly we will be filling the system with test data and I
> > will be glad to help out as much as possible (which may not be much in
> > the way of code, as I've got my hands rather full right now).
>
> Great, we need some people keeping us honest. I don't think any of the
> core developers have >2Gb databases (I sure don't).
I have one, but it's not for production, just a test data.
> 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 to admit that >2GB support is one of the most important issues
but not so sure if it's a show stopper for 6.5.
o even if it's solved, still other many issues for huge databases
still remain:- 4G-tuples-per-database problem (as you said)- index files cannot extend >2GB- vacuuming a huge table
willtake unacceptable long time (Ihave heard vacuum speeds up for 6.5, but I have not tried ityet for a big table. so
thisis just a my guess)
o it will take long time to solve all of them.
---
Tatsuo Ishii
