Re: index cost estimation

Ronan Dunklau <ronan.dunklau@aiven.io>

From: Ronan Dunklau <ronan.dunklau@aiven.io>
To: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-bugs@lists.postgresql.org
Cc: Hung Nguyen <hungnq1989@gmail.com>, pgsql-bugs@lists.postgresql.org, "rjuju123@gmail.com" <rjuju123@gmail.com>, Ronan Dunklau <ronan.dunklau@aiven.io>
Date: 2022-07-06T15:42:28Z
Lists: pgsql-bugs

Attachments

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

Commits

  1. Improve GIN cost estimation