From: | "a(dot)rybakina" <a(dot)rybakina(at)postgrespro(dot)ru> |
---|---|
To: | Lepikhov Andrei <lepikhov(at)fastmail(dot)com> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org, Дамир Белялов <d(dot)belyalov(at)postgrespro(dot)ru>, Richard Guo <guofenglinux(at)gmail(dot)com>, Andrei Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru> |
Subject: | Re: EXPLAIN Verbose issue - custom_scan_tlist can directly refer CTE and Subquery |
Date: | 2023-10-10 14:01:54 |
Message-ID: | b6292f36-8856-4cd4-9d6c-ba995a19992f@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 09.10.2023 11:41, Andrei Lepikhov wrote:
> After some attempts to resolve this issue, I must admit that we should
> add a non-trivial method in the CustomScan node interface, which would
> be called in the ruleutils code.
> I guess it is too much for such a rare situation. So maybe just add a
> documentation entry on this thing and set a couple of assertions on
> early detection of problems?.
> In the attachment - is an offer on how to change the code.
>
Hi!
I have studied the problem and I agree with your suggestion to disable
the possibility of explaining subqueries in CustomNode for now.
So far I can only find information about HashJoin and ValueScan, but I
expected that this is not what is needed.
(gdb) p *((Plan *)(cscan->custom_plans->elements[0].ptr_value))->lefttree
$29 = {type = T_ValuesScan, startup_cost = 0, total_cost =
0.025000000000000001, plan_rows = 2, plan_width = 4, parallel_aware =
false, parallel_safe = true, async_capable = false, plan_node_id = 0,
targetlist = 0x560fc9979398, qual = 0x0, lefttree = 0x0, righttree =
0x0, initPlan = 0x0, extParam = 0x0, allParam = 0x0}
(gdb) p *((Plan *)(cscan->custom_plans->elements[0].ptr_value))
$30 = {type = T_HashJoin, startup_cost = 0.050000000000000003,
total_cost = 0.10250000000000001, plan_rows = 2, plan_width = 32,
parallel_aware = false, parallel_safe = false, async_capable = false,
plan_node_id = 0, targetlist = 0x560fc9979208, qual = 0x0, lefttree =
0x560fc9979438, righttree = 0x560fc9979958, initPlan = 0x0, extParam =
0x0, allParam = 0x0}
(gdb) p *((Plan *)(cscan->custom_plans->elements[0].ptr_value))->righttree
$31 = {type = T_Hash, startup_cost = 0.025000000000000001, total_cost =
0.025000000000000001, plan_rows = 2, plan_width = 32, parallel_aware =
false, parallel_safe = false, async_capable = false,
plan_node_id = 0, targetlist = 0x560fc9979518, qual = 0x0, lefttree =
0x560fc9979698, righttree = 0x0, initPlan = 0x0, extParam = 0x0,
allParam = 0x0}
(gdb) p *((Plan *)(cscan->custom_plans->elements[0].ptr_value))->lefttree
$32 = {type = T_ValuesScan, startup_cost = 0, total_cost =
0.025000000000000001, plan_rows = 2, plan_width = 4, parallel_aware =
false, parallel_safe = true, async_capable = false, plan_node_id = 0,
targetlist = 0x560fc9979398, qual = 0x0, lefttree = 0x0, righttree =
0x0, initPlan = 0x0, extParam = 0x0, allParam = 0x0}
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2023-10-10 15:20:18 | Re: BUG #18153: Undefined Symbol creating postgis_raster extension |
Previous Message | PG Bug reporting form | 2023-10-10 12:02:05 | BUG #18153: Undefined Symbol creating postgis_raster extension |