Re: [HACKERS] why not parallel seq scan for slow functions
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: [HACKERS] why not parallel seq scan for slow functions |
| Дата | |
| Msg-id | 14748.1509939476@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: [HACKERS] why not parallel seq scan for slow functions (Robert Haas <robertmhaas@gmail.com>) |
| Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes:
> This looks like it's on the right track to me. I hope Tom will look
> into it, but if he doesn't I may try to get it committed myself.
I do plan to take a look at it during this CF.
> + /* Set or update cheapest_total_path and related fields */
> + set_cheapest(current_rel);
> I wonder if it's really OK to call set_cheapest() a second time for
> the same relation...
It's safe enough, we do it in some places already when converting
a relation to dummy. But having to do that in a normal code path
suggests that something's not right about the design ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера