From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: remove BufferBlockPointers for speed and space |
Date: | 2005-08-12 05:14:22 |
Message-ID: | 4394.1123823662@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
"Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> writes:
> I've patched the code according to your suggestion. Result is:
> [ snip ]
OK, that test seems a little more believable. One point you didn't
consider is that on 64-bit machines, the integer bufnum really has
to be coerced to size_t to avoid overflow if the buffer array exceeds
2Gb. (Which we don't support today, but might well by the end of
day tomorrow, seeing that there's a patch in the queue about it.)
But I ran the test case with the extra coercion on an IA64 machine at
Red Hat, and got substantially the same results as you did: the array
method is just slower. Another consideration is that the array is
competing for L2 cache --- the test program can't really show that,
since it has no other use for L2 cache, but in the context of the real
database I suspect this is at least as much of a win as shaving a few
nanoseconds off the BufferGetBlock macro itself.
So ... patch applied, and thanks for the good idea!
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-08-12 05:29:58 | Re: Bug in canonicalize_path() |
Previous Message | Bruce Momjian | 2005-08-12 04:51:13 | Re: Bug in canonicalize_path() |