Re: BUG #9553: why bitmap index scan startup_cost=0? it's a bug? - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #9553: why bitmap index scan startup_cost=0? it's a bug?
Date
Msg-id 15025.1394719505@sss.pgh.pa.us
Whole thread Raw
In response to BUG #9553: why bitmap index scan startup_cost=0? it's a bug?  (digoal@126.com)
List 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

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #9552: IndexOnlyScan startup_cost>0, why not equal 0?it's a bug?
Next
From: Tom Lane
Date:
Subject: Re: BUG #9555: pg_dump for tables with inheritance recreates the table with the wrong order of columns