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