From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Janes <jeff.janes@gmail.com>
cc: Thomas Kellerer <spam_eater@gmx.net>,
        pgsql-hackers <pgsql-hackers@postgresql.org>,
        Teodor Sigaev <teodor@sigaev.ru>,
        Alexander Korotkov <a.korotkov@postgrespro.ru>
Subject: Re: Bloom index cost model seems to be wrong
In-reply-to: 
 <CAMkU=1yJh5t8FA3V03PZ567ONfk+6LjS-eDMrgUetMoWouxAaQ@mail.gmail.com>
References: <dc54f6e8-c6bf-6869-08c2-de855de470ae@gmx.net>
 <2126.1549986118@sss.pgh.pa.us>
 <CAMkU=1x9ML8PPmPKM0x7OVv6oUFn4b8s50suj2jcCOT78TLkzQ@mail.gmail.com>
 <CAMkU=1xyzYcjHdCdt8pcY4rvoh0xeP1kb8kvhWiF5fyTYFgBPA@mail.gmail.com>
 <3997.1550006243@sss.pgh.pa.us>
 <CAMkU=1yQRri4-uiFDE=HoBPDDR4PWXB9coS5_kN=7f+vWVL9GQ@mail.gmail.com>
 <CAMkU=1yJh5t8FA3V03PZ567ONfk+6LjS-eDMrgUetMoWouxAaQ@mail.gmail.com>
Comments: In-reply-to Jeff Janes <jeff.janes@gmail.com>
	message dated "Thu, 28 Feb 2019 13:11:16 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <20590.1551378611.1@sss.pgh.pa.us>
Date: Thu, 28 Feb 2019 13:30:11 -0500
Message-ID: <20591.1551378611@sss.pgh.pa.us>
Precedence: bulk

Jeff Janes <jeff.janes@gmail.com> writes:
> 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.

Heap-access costs are added on in costsize.c, not in the index
cost estimator.  I don't remember at the moment whether there's
any explicit accounting for lossy indexes (i.e. false positives).
Up to now, there haven't been cases where we could estimate the
false-positive rate with any accuracy, so we may just be ignoring
the effect.  But if we decide to account for it, I'd rather have
costsize.c continue to add on the actual cost, perhaps based on
a false-positive-rate fraction returned by the index estimator.

			regards, tom lane