Re: [HACKERS] 6.5 TODO list
От | Tatsuo Ishii |
---|---|
Тема | Re: [HACKERS] 6.5 TODO list |
Дата | |
Msg-id | 199905120057.JAA00744@ext16.sra.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] 6.5 TODO list (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] 6.5 TODO list
|
Список | pgsql-hackers |
> 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
В списке pgsql-hackers по дате отправления: