2011/10/8 Tom Lane <t...@sss.pgh.pa.us>: > 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?
No preferences, but is it interesting to add a "vacuum freeze" somewhere and check expected result after index-only scan ? (for both idx_tup_read and idx_tup_fetch) > > regards, tom lane > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Cédric Villemain +33 (0)6 20 30 22 52 http://2ndQuadrant.fr/ PostgreSQL: Support 24x7 - Développement, Expertise et Formation -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
