Heikki Linnakangas wrote:
On 28.06.2011 20:47, Kevin Grittner wrote:
Hmm, the calls in question are the ones in heapgettup() and
heapgettup_pagemode(), which are subroutines of heap_getnext().
heap_getnext() is only used in sequential scans, so it seems safe
to remove those calls.
I haven't found anything to the contrary, if I understand correctly,
Dan found the same, and all the tests pass without them. Here's a
patch to remove them. This makes the recently-added
rs_relpredicatelocked boolean field unnecessary, so that's removed in
this patch, too.
I would like to add a test involving a lossy bitmap scan. How many
rows are normally needed to force a bitmap scan to be lossy?
The size of bitmaps is controlled by work_mem, so you can set
work_mem very small to cause them to become lossy earlier. Off the
top of my head I don't have any guesstimate on how many rows you
What's the easiest way to check whether a plan is going to use (or
is using) a lossy bitmap scan?
Good question. There doesn't seem to be anything in the EXPLAIN
ANALYZE output to show that, so I think you'll have to resort to
adding some elog()s in the right places.
OK, thanks.


Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 7 of 9 | next ›
Discussion Overview
grouppgsql-hackers @
postedJun 27, '11 at 6:24p
activeJun 29, '11 at 7:48p



site design / logo © 2021 Grokbase