Re: index cost estimation

From: Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Cc: Hung Nguyen <hungnq1989(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org, "rjuju123(at)gmail(dot)com" <rjuju123(at)gmail(dot)com>, Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>
Subject: Re: index cost estimation
Date: 2022-07-06 15:42:28
Message-ID: 3439542.iIbC2pHGDl@aivenronan
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
v1-0001-Fix-gin-costing.patch text/x-patch 2.8 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2022-07-06 22:07:46 Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower
Previous Message Ronan Dunklau 2022-07-06 14:52:09 Re: index cost estimation