Re: remove BufferBlockPointers for speed and space

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-11 13:39:21
Message-ID: 21559.1123767561@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:
> The source code is attached.

> gettimeofday(&start_t, NULL);
> if (method == 0)
> {
> for (i = 0; i < NBuffers; i++)
> k = array[i];
> }
> if (method == 1)
> {
> for (i = 0; i < NBuffers; i++)
> k = start + i*BLCKSZ;
> }
> if (method == 2)
> {
> for (i = 0; i < NBuffers; i++)
> k = start + (i<<13);
> }
> gettimeofday(&stop_t, NULL);

This is definitely going to tell us a lot more about the compiler's loop
strength reduction algorithms than it is going to tell about the time to
evaluate any one of these expressions in isolation. What's worse, the
compiler would be quite within its rights to detect that k isn't used
anywhere, and optimize the loop away completely.

What I would suggest is first to fill another array with some large
number of buffer numbers (randomly chosen from 1..N) and then time loops
of the form

for (i = 0; i < arraysize; i++)
{
bn = buffernumbers[i];
bufferlocs[i] = BufferGetBlock(bn);
}

for all three possible definitions of BufferGetBlock (where both arrays
are global variables, just to be sure the compiler doesn't think it can
discard the store). This should give some numbers worth trusting.

regards, tom lane

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Matt Miller 2005-08-11 15:04:36 Re: PL/pgSQL: #option select_into_1_row (was SELECT INTO
Previous Message Andrew Dunstan 2005-08-11 12:53:08 Re: remove BufferBlockPointers for speed and space