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.
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
Open Source Engineeering Departmeent,
NTT DATA Intellilink Corporation
Phone: +81-3-5566-9628 WWW: http://www.intellilink.co.jp
In response to
pgsql-hackers by date
|Next:||From: Martijn van Oosterhout||Date: 2005-09-02 13:04:21|
|Subject: Proof of concept COLLATE support with patch|
|Previous:||From: Hannu Krosing||Date: 2005-09-02 06:36:26|
|Subject: Question about explain of index scan|
pgsql-patches by date
|Next:||From: Atsushi Ogawa||Date: 2005-09-02 12:09:55|
|Subject: Re: sum(int4)/sum(int2) improvement|
|Previous:||From: Tino Wildenhain||Date: 2005-09-02 05:38:31|
|Subject: Re: typo? was: Version number in psql banner|