mirror of
https://github.com/postgres/postgres.git
synced 2026-02-16 00:57:52 -05:00
aea916fe55
The bitmap heap scan skip fetch optimization skips fetching the heap block when a page is set all-visible in the visibility map and no columns from the table are needed to satisfy the query.2b73a8cd33andc3953226a0changed the control flow of bitmap heap scan to use the read stream API. The read stream API returns buffers containing blocks to the user. To make this work with the skip fetch optimization, we keep a count of the empty tuples we need to emit for all the blocks skipped and only emit the empty tuples after processing the next block fetched from the heap or at the end of the scan. It's incorrect to recheck NULL tuples, so we must set `recheck` to false before yielding control back to BitmapHeapNext(). This was done before emitting any remaining empty tuples at the end of the scan but not for empty tuples emitted during the scan. This meant that if a page fetched from the heap did require recheck and set `recheck` to true and then we emitted empty tuples for subsequent blocks, we would get wrong results. Fix this by always setting `recheck` to false before emitting empty tuples. Reported-by: Alexander Lakhin <exclusion@gmail.com> Tested-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/496f7acd-881c-4df3-9bd3-8f8534dfec26%40gmail.com
47 lines
1.7 KiB
SQL
47 lines
1.7 KiB
SQL
-- Test bitmap AND and OR
|
|
|
|
|
|
-- Generate enough data that we can test the lossy bitmaps.
|
|
|
|
-- There's 55 tuples per page in the table. 53 is just
|
|
-- below 55, so that an index scan with qual a = constant
|
|
-- will return at least one hit per page. 59 is just above
|
|
-- 55, so that an index scan with qual b = constant will return
|
|
-- hits on most but not all pages. 53 and 59 are prime, so that
|
|
-- there's a maximum number of a,b combinations in the table.
|
|
-- That allows us to test all the different combinations of
|
|
-- lossy and non-lossy pages with the minimum amount of data
|
|
|
|
CREATE TABLE bmscantest (a int, b int, t text) WITH (autovacuum_enabled = false);
|
|
|
|
INSERT INTO bmscantest
|
|
SELECT (r%53), (r%59), 'foooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo'
|
|
FROM generate_series(1,70000) r;
|
|
|
|
CREATE INDEX i_bmtest_a ON bmscantest(a);
|
|
CREATE INDEX i_bmtest_b ON bmscantest(b);
|
|
|
|
-- We want to use bitmapscans. With default settings, the planner currently
|
|
-- chooses a bitmap scan for the queries below anyway, but let's make sure.
|
|
set enable_indexscan=false;
|
|
set enable_seqscan=false;
|
|
|
|
-- Lower work_mem to trigger use of lossy bitmaps
|
|
set work_mem = 64;
|
|
|
|
-- Test bitmap-and without the skip fetch optimization.
|
|
SELECT count(*) FROM bmscantest WHERE a = 1 AND b = 1;
|
|
|
|
-- Test that we return correct results when using the skip fetch optimization
|
|
-- VACUUM FREEZE will set all the pages in the relation all-visible, enabling
|
|
-- the optimization.
|
|
VACUUM (FREEZE) bmscantest;
|
|
|
|
SELECT count(*) FROM bmscantest WHERE a = 1 AND b = 1;
|
|
|
|
-- Test bitmap-or.
|
|
SELECT count(*) FROM bmscantest WHERE a = 1 OR b = 1;
|
|
|
|
|
|
-- clean up
|
|
DROP TABLE bmscantest;
|