Re: Bloom index cost model seems to be wrong

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-hackers <pgsql-hackers(at)postgresql(dot)org>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
Subject: Re: Bloom index cost model seems to be wrong
Date: 2019-02-28 18:11:16
Message-ID: CAMkU=1yJh5t8FA3V03PZ567ONfk+6LjS-eDMrgUetMoWouxAaQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

On Sun, Feb 24, 2019 at 11:09 AM Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:

> I've moved this to the hackers list, and added Teodor and Alexander of the
> bloom extension, as I would like to hear their opinions on the costing.
>

My previous patch had accidentally included a couple lines of a different
thing I was working on (memory leak, now-committed), so this patch removes
that diff.

I'm adding it to the commitfest targeting v13. I'm more interested in
feedback on the conceptual issues rather than stylistic ones, as I would
probably merge the two functions together before proposing something to
actually be committed.

Should we be trying to estimate the false positive rate and charging
cpu_tuple_cost and cpu_operator_cost the IO costs for visiting the table to
recheck and reject those? I don't think other index types do that, and I'm
inclined to think the burden should be on the user not to create silly
indexes that produce an overwhelming number of false positives.

Cheers,

Jeff

Attachment Content-Type Size
bloom_cost_v3.patch application/octet-stream 6.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-02-28 18:11:44 Re: Drop type "smgr"?
Previous Message Shawn Debnath 2019-02-28 18:06:20 Re: Drop type "smgr"?

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2019-02-28 18:30:11 Re: Bloom index cost model seems to be wrong
Previous Message Jung, Jinho 2019-02-28 16:43:26 Re: Performance regressions found using sqlfuzz