BUG #9553: why bitmap index scan startup_cost=0? it's a bug?
The following bug has been logged on the website:
Bug reference: 9553
Logged by: digoal.zhou
Email address: digoal@126.com
PostgreSQL version: 9.3.3
Operating system: CentOS 6.4 x64
Description:
Bitmap index scan need sort the indexenrty by heap_page_id first, then out
put the sorted heappageid to next node, but why bitmap index scan node's
startup_cost=0?
digoal=# explain (analyze,verbose,buffers,costs,timing) select id from t11
where id<10000;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------
Bitmap Heap Scan on public.t11 (cost=93.95..354.20 rows=10020 width=4)
(actual time=1.447..3.907 rows=9999 loops=1)
Output: id
Recheck Cond: (t11.id < 10000)
Buffers: shared hit=22
-> Bitmap Index Scan on t11_pkey (cost=0.00..91.44 rows=10020 width=0)
(actual time=1.370..1.370 rows=9999 loops=1)
Index Cond: (t11.id < 10000)
Buffers: shared hit=8
Total runtime: 4.931 ms
(8 rows)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Hello,
Bitmap index scan need sort the indexenrty by heap_page_id
first, then out put the sorted heappageid to next node, but why
bitmap index scan node's startup_cost=0?
I don't understand what you mean by 'heap_page_id sort' but it is
also not a bug.
The bitmap index scan is a mere part of bitmap heap scan and the
startup costs of the underlying bitmap index scans are not needed
to estimate the cost of the whole index heap scan.
Additionally, total cost of index scan doesn't include final
startup cost (which includes disable_cost) perhaps intentionally
to avoid enable_indexscan = false from affecting bitmap index
scans. As the result, the bare startup cost calculated
amcostestimate is not stored anywhere. The startup costs shows up
in the bitmap index scans are actually incorrect precisely but
does no harm.
# Correct?
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
digoal@126.com writes:
Bitmap Heap Scan on public.t11 (cost=93.95..354.20 rows=10020 width=4)
(actual time=1.447..3.907 rows=9999 loops=1)
Output: id
Recheck Cond: (t11.id < 10000)
Buffers: shared hit=22
-> Bitmap Index Scan on t11_pkey (cost=0.00..91.44 rows=10020 width=0)
(actual time=1.370..1.370 rows=9999 loops=1)
Index Cond: (t11.id < 10000)
Buffers: shared hit=8
Total runtime: 4.931 ms
We don't bother to store/show the indexscan's startup cost in such cases,
since it has no effect whatsoever on subsequent planning: the total cost
of the indexscan will go into the parent's startup cost anyway.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs