Re: MergeAppend could consider sorting cheapest child path
| От | Andrei Lepikhov |
|---|---|
| Тема | Re: MergeAppend could consider sorting cheapest child path |
| Дата | |
| Msg-id | ebb22581-e4c5-4ea3-90ac-dbbcb3020529@gmail.com обсуждение исходный текст |
| Ответ на | Re: MergeAppend could consider sorting cheapest child path (Alexander Pyhalov <a.pyhalov@postgrespro.ru>) |
| Ответы |
Re: MergeAppend could consider sorting cheapest child path
Re: MergeAppend could consider sorting cheapest child path |
| Список | pgsql-hackers |
On 4/29/25 19:25, Alexander Pyhalov wrote: > Andrei Lepikhov писал(а) 2025-04-29 16:52: > But it seems, base_path can't be NULL Correct. Fixed. > > Also we check base_path for required_outer and require_parallel_safe, > but if cheapest path for pathkeys is NULL, these checks are not > performed. Thanks. Fixed. > Luckily, they seen to be no-op anyway due to cheapest_total- > >param_info == NULL and function arguments being NULL (required_outer) > and false (require_parallel_safe). Should we do something about this? > Don't know, perhaps, remove these misleading arguments? The main reason why I introduced these _ext routines was that this schema may be used somewhere else. And in that case parameterised paths may exist. Who knows, may be parameterised paths will be introduced for merge append too? > become no-op? And we do return non-null path from > get_cheapest_fractional_path_for_pathkeys_ext(), as it seems we return > either cheapest_total_path or cheapest fractional path from > get_cheapest_fractional_path_for_pathkeys_ext(). Ok. Let's check next version of the patch in the attachment. -- regards, Andrei Lepikhov
Вложения
В списке pgsql-hackers по дате отправления: