Quite some time ago I complained about the fact that bitmap index scans
weren't being counted sanely by the statistics mechanism:
http://archives.postgresql.org/pgsql-hackers/2005-04/msg00675.php
That discussion trailed off without deciding how to fix it, but we
really can't let this go without fix
On R, 2005-04-22 at 13:46 -0700, Josh Berkus wrote:
> Tom,
>
> Hmmm ... we need to flag *something* in pg_stat_*_indexes, whether it is a
> new
> column or the tuplefetch column. People use that view to find indexes they
> can drop.
I think that "idx_scan" and "idx_tup_read" can have the sam
Josh Berkus writes:
>> I've never fully understood the distinction the stats make between
>> "tuples fetched" and "tuples returned", and it's even less obvious how
>> to apply it when the index and heap operations are decoupled.
> Well, it's mainly a counter to measure how many dead rows are in
Tom,
Hmmm ... we need to flag *something* in pg_stat_*_indexes, whether it is a new
column or the tuplefetch column. People use that view to find indexes they
can drop.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
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 ro
Josh Berkus writes:
> Well, technically a bitmapscan is a different operation. So it should
> probably have its own columns. Unless you're talking about an overhaul of
> the stats views more drastic than that? If so, what?
That was basically what I was asking: do we expand all the stats su
On 4/22/2005 3:53 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
tuples fetched is the number of raw, possibly dead tuples fetched from
the heap. Tuples returned is the number of alive tuples ... IIRC.
No, count_heap_fetch only counts tuples that have already passed the
snapshot test.
Tom,
> I've never fully understood the distinction the stats make between
> "tuples fetched" and "tuples returned", and it's even less obvious how
> to apply it when the index and heap operations are decoupled.
Well, it's mainly a counter to measure how many dead rows are in your active
data se
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 scan
On 4/22/2005 3:30 PM, Tom Lane wrote:
Josh Berkus writes:
Well, technically a bitmapscan is a different operation. So it should
probably have its own columns. Unless you're talking about an overhaul of
the stats views more drastic than that? If so, what?
That was basically what I was asking
Jan Wieck <[EMAIL PROTECTED]> writes:
> tuples fetched is the number of raw, possibly dead tuples fetched from
> the heap. Tuples returned is the number of alive tuples ... IIRC.
No, count_heap_fetch only counts tuples that have already passed the
snapshot test. It could be that the places where
Tom,
> 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 d
12 matches
Mail list logo
