On Tue, Feb 12, 2019 at 10:42 AM Tom Lane <t...@sss.pgh.pa.us> wrote:
> Thomas Kellerer <spam_ea...@gmx.net> writes: > > The bloom index is only used if either Seq Scan is disabled or if the > random_page_cost is set to 1 (anything about 1 triggers a Seq Scan on my > Windows laptop). > > Hm. blcostestimate is using the default cost calculation, except for > > /* We have to visit all index tuples anyway */ > costs.numIndexTuples = index->tuples; > > which essentially tells genericcostestimate to assume that every index > tuple will be visited. This obviously is going to increase the cost > estimate; maybe there's something wrong with that? > I assumed (without investigating yet) that genericcostestimate is applying a cpu_operator_cost (or a few of them) on each index tuple, while the premise of a bloom index is that you do very fast bit-fiddling, not more expense SQL operators, for each tuple and then do the recheck only on what survives to the table tuple part. Cheers, Jeff
