Skip site navigation (1) Skip section navigation (2)

Re: A couple of patches for PostgreSQL 64bit support

From: Koichi Suzuki <koichi(at)intellilink(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches(at)postgresql(dot)org,Satoshi Nagayasu <nagayasus(at)nttdata(dot)co(dot)jp>, ikubo(at)intellilink(dot)co(dot)jp,yasunaga <yasunaga(dot)hisato(at)soft(dot)fujitsu(dot)com>,Bruce Momjian <root(at)candle(dot)pha(dot)pa(dot)us>,Jan Wieck <JanWieck(at)Yahoo(dot)com>, sakata(dot)tetsuo(at)lab(dot)ntt(dot)co(dot)jp,"T(dot)Honishi" <honishi(dot)takashi(at)lab(dot)ntt(dot)co(dot)jp>
Subject: Re: A couple of patches for PostgreSQL 64bit support
Date: 2005-09-02 10:36:42
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
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:

In response to

pgsql-hackers by date

Next:From: Martijn van OosterhoutDate: 2005-09-02 13:04:21
Subject: Proof of concept COLLATE support with patch
Previous:From: Hannu KrosingDate: 2005-09-02 06:36:26
Subject: Question about explain of index scan

pgsql-patches by date

Next:From: Atsushi OgawaDate: 2005-09-02 12:09:55
Subject: Re: sum(int4)/sum(int2) improvement
Previous:From: Tino WildenhainDate: 2005-09-02 05:38:31
Subject: Re: typo? was: Version number in psql banner

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group