Re: A couple of patches for PostgreSQL 64bit support

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 <koichi(at)intellilink(dot)co(dot)jp> 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
------------------------------------------