Re: Bitmap scans vs. the statistics views

I'm currently finding that the stats regression test fails with
bitmapped index scans enabled:

*** 62,68 ****
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,
--- 62,68 ----
WHERE st.relname='tenk2' AND cl.relname='tenk2';
?column? | ?column? | ?column? | ?column?
----------+----------+----------+----------
! t | t | f | f
(1 row)

SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages,

The reason for this appears to be that the standard stats views
disregard tuples_fetched for tables, but tuples_fetched is the only
counter that's getting bumped in a bitmap scan.

I could probably add some code to bump tuples_returned as well,
but I wonder whether something more drastic isn't needed. The
stats views seem to be designed around the assumption that there
are seqscans and indexscans and nothing else. Do we need to
expand the number of functions and rows to allow for a third basic
scan type, or do we want to fuzz things up?

Comments anyone?

regards, tom lane

I would like to know if bitmap scans are being used on a table. I think
it's worth adding to the stats views, though I'm not sure on the best
way. For example, this means that a query on one table can now scan
multiple indexes, but it doesn't seem right to lump that in with
'traditional' index scans. An extreme view would be to add new bitmap
scan columns to pg_stat(io)_(tables|indexes), but that might be
overkill.
--
Jim C. Nasby, Database Consultant decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"