| From: | Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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> |
| Subject: | Re: index cost estimation |
| Date: | 2022-07-06 14:52:09 |
| Message-ID: | 2187702.iZASKD2KPV@aivenronan |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
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.
--
Ronan Dunklau
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ronan Dunklau | 2022-07-06 15:42:28 | Re: index cost estimation |
| Previous Message | Tom Lane | 2022-07-06 14:41:29 | Re: index cost estimation |