Thanks a lot for the port to CVS. I agree that we need more benckmark efforts to clarify real outcome of "more than 2GB" memory. Please let me spend some more for this. I will post benchmark results. As long as I see from pgbench, it looks more memory gets more throuput. Maybe big SQL against big dataset is another example to show the effect.
I also agree that we need much more study to show the effect of 64bit TID (and perhaps CID). Based on the patch I posted, I'll continue my effort and also post the results for discussion. Best Regards; Tom Lane wrote: > Koichi Suzuki <[EMAIL PROTECTED]> writes: > >>Here're a couple of patches for PostgreSQL 64bit support. There're just >>two extension to 64bit, size of shared memory and transaction ID. > > > I've applied the part of this that seemed reasonably noncontroversial, > namely the fixes to do shared memory size calculation in size_t > arithmetic instead of int arithmetic. (While at it, I extended the Size > convention to all the shared memory sizing routines, not just buffers, > and added code to detect overflows in the calculations. That way we > don't need a "64 bit" configure switch.) While I still remain > unconvinced that there's any real-world need for more than 2Gb of > shared_buffers, this change certainly makes the code more robust against > configuration errors, and it has essentially zero cost (except maybe a > few more milliseconds during postmaster start). > > On the other hand, I think the 64-bit XID idea needs considerably more > work before being proposed again. That would incur serious costs due > to the expansion of tuple headers, and there's no evidence that the > distributed cost would be bought back by avoiding one vacuum pass every > billion transactions. (Your description of the patch claimed that > vacuuming requires shutting down the database, which is simply wrong.) > Also, as previously noted, you can't just whack the size of XID around > without considering side-effects on CID, OID, Datum, etc. > > regards, tom lane > -- ------------------------------------------- Koichi Suzuki Open Source Engineeering Departmeent, NTT DATA Intellilink Corporation Phone: +81-3-5566-9628 WWW: http://www.intellilink.co.jp ------------------------------------------ ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
