Re: index cost estimation - Mailing list pgsql-bugs

From Ronan Dunklau
Subject Re: index cost estimation
Date
Msg-id 3439542.iIbC2pHGDl@aivenronan
Whole thread Raw
In response to Re: index cost estimation  (Ronan Dunklau <ronan.dunklau@aiven.io>)
List pgsql-bugs
Le mercredi 6 juillet 2022, 16:52:09 CEST Ronan Dunklau a écrit :
> Le mercredi 6 juillet 2022, 16:41:29 CEST Tom Lane a écrit :
> > Hm, so it'd seem this probably could happen when comparing *any*
> > non-btree index to a btree index, because I don't think we are
> > particularly careful with CPU cost estimation for any of the
> > other index types.  If we do something about this, we probably
> > have to look at all of them.
>
> For gist and sp-gist, a descent cost is taken into account, by estimating
the
> tree height so that particular effect is mitigated. Whether the cpu cost
> estimation is sensible regarding to btree is another topic, but at least the
> index cost doesn't vanish when inside a loop.
>
> Hash, brin and bloom are quite different, so maybe another examination would
be
> required but probably outside the scope of this bug report.

Here is a patch tentatively addressing the problem. I'm not sure what I'm
doing with the number of searched entries is right though.


--
Ronan Dunklau
Attachment

pgsql-bugs by date:

Previous
From: Ronan Dunklau
Date:
Subject: Re: index cost estimation
Next
From: "David G. Johnston"
Date:
Subject: Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower