From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
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 08:14:28 |
Message-ID: | 20140313.171428.80654359.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | marko | 2014-03-13 09:39:22 | BUG #9557: Row not visible after receiving notification |
Previous Message | Kyotaro HORIGUCHI | 2014-03-13 05:34:26 | Re: BUG #9552: IndexOnlyScan startup_cost>0, why not equal 0?it's a bug? |