Re: [HACKERS] 6.5 TODO list

> Christopher Masto <chris(at)netmonger(dot)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 will take unacceptable long time (I
have heard vacuum speeds up for 6.5, but I have not tried it
yet for a big table. so this is just a my guess)

o it will take long time to solve all of them.
---
Tatsuo Ishii