| От | Ronan Dunklau |
|---|---|
| Тема | Re: index cost estimation |
| Дата | |
| Msg-id | 3439542.iIbC2pHGDl@aivenronan обсуждение исходный текст |
| Ответ на | Re: index cost estimation (Ronan Dunklau <ronan.dunklau@aiven.io>) |
| Список | 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
В списке pgsql-bugs по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера