| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | digoal(at)126(dot)com |
| Cc: | pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #9553: why bitmap index scan startup_cost=0? it's a bug? |
| Date: | 2014-03-13 14:05:05 |
| Message-ID: | 15025.1394719505@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
digoal(at)126(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2014-03-13 14:19:00 | Re: BUG #9555: pg_dump for tables with inheritance recreates the table with the wrong order of columns |
| Previous Message | Tom Lane | 2014-03-13 13:56:35 | Re: BUG #9552: IndexOnlyScan startup_cost>0, why not equal 0?it's a bug? |