Re: EXPLAIN Verbose issue - custom_scan_tlist can directly refer CTE and Subquery

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}

In response to

Browse pgsql-bugs by date

  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