Re: BUG #19102: Assertion failure in generate_orderedappend_paths with aggregate pushdown
| От | Andrei Lepikhov |
|---|---|
| Тема | Re: BUG #19102: Assertion failure in generate_orderedappend_paths with aggregate pushdown |
| Дата | |
| Msg-id | e90abc7c-3d59-4f7b-9def-e43c4a6d587e@gmail.com обсуждение исходный текст |
| Ответ на | Re: BUG #19102: Assertion failure in generate_orderedappend_paths with aggregate pushdown (Richard Guo <guofenglinux@gmail.com>) |
| Ответы |
Re: BUG #19102: Assertion failure in generate_orderedappend_paths with aggregate pushdown
|
| Список | pgsql-bugs |
On 4/11/2025 08:44, Richard Guo wrote: > Any thoughts?The first patch looks good, but I still have a couple of questions. 1. We don't use parameterised paths in MergeAppend yet. I wonder if it could be nudged by spreading the use of partitioned tables with foreign partitions. Do you think, in such a case, the usage of cheapest_total->rows will stay correct? It seems that the parameterised path has much less estimation than the RelOptInfo... 2. I understand why the upper relation has unset nrows. However, it may be more accurate to set row estimation for a pushing-down upper RelOptInfo. Or, at least, describe in comments why this is desirable behaviour. It would be profitable, at least, for extension developers. I also support the second patch. With many partitions, it allows us to save a significant amount of CPU cycles. -- regards, Andrei Lepikhov, pgEdge
В списке pgsql-bugs по дате отправления: