Re: BUG #15947: Worse plan is chosen after giving the planner morefreedom (partitionwise join)
В списке pgsql-bugs по дате отправления:
| От | Erik Rijkers |
|---|---|
| Тема | Re: BUG #15947: Worse plan is chosen after giving the planner morefreedom (partitionwise join) |
| Дата | |
| Msg-id | a68a00b2971fa21bc2ee3a3f7df9d916@xs4all.nl обсуждение |
| Ответ на | BUG #15947: Worse plan is chosen after giving the planner more freedom (partitionwise join) (PG Bug reporting form <noreply@postgresql.org>) |
| Список | pgsql-bugs |
On 2019-08-11 00:28, PG Bug reporting form wrote: > The following bug has been logged on the website: > > Bug reference: 15947 > I'm trying the following query: > > EXPLAIN > SELECT COUNT(*) > FROM sc > WHERE EXISTS ( > SELECT 1 > FROM sg > WHERE sc.id = sg.sc_fk > AND sc.a = sg.a > AND sc.o = sg.o > AND sc.sl = sg.sl > ); > > Which produces the plan with this cost estimation (top node): > -- Aggregate (cost=147.25..147.26 rows=1 width=8) > > But after: > SET enable_partitionwise_join = true; > > The new plan is more expensive: > -- Aggregate (cost=175.00..175.01 rows=1 width=8) > > This shouldn't be happening, right? Why not? The 'worse plan' cnsistently executes faster. I don't think the cost units of different queries can/should be compared as if they are the same.
В списке pgsql-bugs по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера