From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Thomas Kellerer <spam_eater(at)gmx(dot)net>, pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: Bloom index cost model seems to be wrong |
Date: | 2019-02-12 16:58:08 |
Message-ID: | CAMkU=1x9ML8PPmPKM0x7OVv6oUFn4b8s50suj2jcCOT78TLkzQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
On Tue, Feb 12, 2019 at 10:42 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thomas Kellerer <spam_eater(at)gmx(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2019-02-12 17:33:46 | Re: Protect syscache from bloating with negative cache entries |
Previous Message | Thomas Kellerer | 2019-02-12 16:54:04 | Re: Should we still have old release notes in docs? |
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2019-02-12 18:03:48 | Re: Performance regressions found using sqlfuzz |
Previous Message | Tom Lane | 2019-02-12 15:41:58 | Re: Bloom index cost model seems to be wrong |