I notice that several members of the buildfarm have been consistently
showing the same regression test failure since the index-only scans
patch went in:
***
/home/pgbuildfarm/workdir/HEAD/pgsql.27150/src/test/regress/expected/stats.out
Sat Oct 8 03:20:05 2011
---
/home/pgbuildfarm/workdir/HEAD/pgsql.27150/src/test/regress/results/stats.out
Sat Oct 8 12:30:55 2011
***************
*** 94,100 ****
WHERE st.relname='tenk2' AND cl.relname='tenk2';
?column? | ?column? | ?column? | ?column?
----------+----------+----------+----------
! t | t | t | t
(1 row)
SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages,
--- 94,100 ----
WHERE st.relname='tenk2' AND cl.relname='tenk2';
?column? | ?column? | ?column? | ?column?
----------+----------+----------+----------
! t | t | t | f
(1 row)
SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages,
The diff indicates that the idx_scan count advanced but idx_tup_fetch
did not, which is not so surprising here because tenk2 hasn't been
modified in some time. If the autovacuum daemon managed to mark it
all-visible before the stats test runs, then an index-only scan will
happen, and bingo, no idx_tup_fetch increment (because indeed no heap
tuple was fetched).
I'm inclined to fix this by changing the test to examine idx_tup_read
not idx_tup_fetch. Alternatively, we could have the test force
enable_indexonlyscan off. Thoughts?
regards, tom lane
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
