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

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 (view raw or flat)
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

pgsql-patches by date

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

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