Re: pgsql: Tweak order of operations in BitmapHeapNext() to avoid the case

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgsql: Tweak order of operations in BitmapHeapNext() to avoid the case
Date: 2009-01-12 17:33:43
Message-ID: 2443.1231781623@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> tgl(at)postgresql(dot)org (Tom Lane) writes:
>> Tweak order of operations in BitmapHeapNext() to avoid the case of prefetching
>> the same page we are nanoseconds away from reading for real. There should be
>> something left to do on the current page before we consider issuing a prefetch.

> Doesn't this break things if, say, there's precisely one tuple on every page?

No. It'd only break things if there were zero tuples on each page, but
that's not possible (else the page wouldn't be in the index output to
begin with).

There is a bit of oddness in how fast the target ramps up, because of
the target++ in the "Continuing in previously obtained page" path.
I wasn't too happy with that target++ to begin with, but am not sure
what's a saner thing to do there.

regards, tom lane

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Alvaro Herrera 2009-01-12 21:02:15 pgsql: Simplify the writing of amoptions routines by introducing a
Previous Message Gregory Stark 2009-01-12 17:19:05 Re: pgsql: Tweak order of operations in BitmapHeapNext() to avoid the case

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Page 2009-01-12 17:34:25 Re: Recovery Test Framework
Previous Message Joshua D. Drake 2009-01-12 17:30:23 Re: Recovery Test Framework