pgsql: Tweak order of operations in BitmapHeapNext() to avoid the case
Log Message:
-----------
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.
Modified Files:
--------------
pgsql/src/backend/executor:
nodeBitmapHeapscan.c (r1.33 -> r1.34)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeBitmapHeapscan.c?r1=1.33&r2=1.34)
tgl@postgresql.org (Tom Lane) writes:
Log Message:
-----------
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?
You'll keep raising the prefetch_target but never actually prefetch anything.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!
Gregory Stark <stark@enterprisedb.com> writes:
tgl@postgresql.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