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 |
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"? |
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 |