From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Richard Guo <guofenglinux(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18576: Using EXPLAIN (VERBOSE) in information_schema.element_types returns ERROR: failed to find plan for |
Date: | 2024-08-19 17:11:00 |
Message-ID: | 5e129a8e-5b8d-4a61-9776-59be99a2c14f@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 19/8/2024 18:36, Tom Lane wrote:
> Andrei Lepikhov <lepihov(at)gmail(dot)com> writes:
>> Thanks for pushing this!
>
>> But could you change this code a little bit?
>> I reported this issue a year ago. At that time, it was triggered by the
>> CustomScan node [1]. I haven't found the solution there [2]. Your code
>> looks like a good tradeoff, and if you slightly change the code (like in
>> the attachment), it allows CustomScan to survive such cases.
>
> This seems like it's making assumptions it shouldn't about what
> CustomScan does. If there's an argument for doing this, it should
> be added to the adjacent comments.
Hm, I got into this problem many times using CustomScan node. Do you
have some objections to not allow CustomScan node have a RECORD Var in
the target list? For example, once I got this bug designing CustomScan
which gathered lightweight statistics on-the-fly under a Sort and
GROUP-BY nodes. I didn't change any tuple and had the same target list
as the child node. Why we should analyse target list and don't use
CustomScan if it contains Var of specific type?
>
> (Also, what's with the random change in contrib/Makefile?)
Oops, it's a waste code, pardon.
--
regards, Andrei Lepikhov
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2024-08-19 17:20:20 | Re: Intermittent aggressive use of SWAP space by PostgreSQL despite availability of HUGE amounts of RAM for a small database. |
Previous Message | Tom Lane | 2024-08-19 16:36:41 | Re: BUG #18576: Using EXPLAIN (VERBOSE) in information_schema.element_types returns ERROR: failed to find plan for |