| From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
|---|---|
| To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org, akorotkov(at)postgresql(dot)org, Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com> |
| Subject: | Re: BUG #19102: Assertion failure in generate_orderedappend_paths with aggregate pushdown |
| Date: | 2025-11-04 13:43:05 |
| Message-ID: | e90abc7c-3d59-4f7b-9def-e43c4a6d587e@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2025-11-04 14:55:28 | Re: BUG #19103: Canceled INSERT statement can still influence the performance of subsequent SELECT statement |
| Previous Message | David G. Johnston | 2025-11-04 13:26:01 | Re: BUG #19103: Canceled INSERT statement can still influence the performance of subsequent SELECT statement |