> Which is properly written as the following, using lateral, which also avoids
> the problem you describe:
>
> INSERT INTO tbl
> SELECT func_call.*
> FROM ft
> JOIN LATERAL convert_func(ft.rawdata) AS func_call ON true;
I didn't fully realize this syntax until you point out. Just try it out in
ou
On Sun, Dec 4, 2022 at 9:37 PM Pavel Stehule
wrote:
>
> po 5. 12. 2022 v 5:28 odesílatel Tom Lane napsal:
>
>> Peifeng Qiu writes:
>> >> the need for this code seems not that great. But as to the code
>> itself I'm unable to properly judge.
>>
>> I mention this because trying to reverse-engine
Pavel Stehule writes:
> po 5. 12. 2022 v 5:28 odesílatel Tom Lane napsal:
>> I tend to agree with David that LATERAL offers a good-enough
>> solution in most cases ... but it is annoying that we accept
>> this syntax and then pessimize it.
> I agree, so there is a perfect solution like don't use
po 5. 12. 2022 v 5:28 odesílatel Tom Lane napsal:
> Peifeng Qiu writes:
> >> the need for this code seems not that great. But as to the code itself
> I'm unable to properly judge.
>
> > A simplified version of my use case is like this:
> > CREATE FOREIGN TABLE ft(rawdata json);
> > INSERT INTO
Peifeng Qiu writes:
>> the need for this code seems not that great. But as to the code itself I'm
>> unable to properly judge.
> A simplified version of my use case is like this:
> CREATE FOREIGN TABLE ft(rawdata json);
> INSERT INTO tbl SELECT (convert_func(rawdata)).* FROM ft;
It might be wo
On Sun, Dec 4, 2022 at 9:00 PM Peifeng Qiu wrote:
> > the need for this code seems not that great. But as to the code itself
> I'm unable to properly judge.
> A simplified version of my use case is like this:
> CREATE FOREIGN TABLE ft(rawdata json);
> INSERT INTO tbl SELECT (convert_func(rawdata
> the need for this code seems not that great. But as to the code itself I'm
> unable to properly judge.
A simplified version of my use case is like this:
CREATE FOREIGN TABLE ft(rawdata json);
INSERT INTO tbl SELECT (convert_func(rawdata)).* FROM ft;
We have a foreign data source that can emit j
On Fri, Dec 2, 2022 at 12:52 AM Peifeng Qiu wrote:
> Hi hackers.
>
> When a star(*) expands into multiple fields, our current
> implementation is to generate multiple copies of the expression
> and do FieldSelects. This is very inefficient because the same
> expression get evaluated multiple time
regards,
Peifeng Qiu
From 52b389466cf397c6e70168a64252abf4c7453ba6 Mon Sep 17 00:00:00 2001
From: Peifeng Qiu
Date: Fri, 2 Dec 2022 16:37:03 +0900
Subject: [PATCH] Optimize common expressions in projection evaluation
When a star(*) expands into multiple fields, our current
implementation is to generate multiple copies
