On Tue, Dec 3, 2024 at 5:33 PM Andrei Lepikhov wrote:
> A couple of words about your patch. These few lines of code caused a lot
> of discoveries, but in my opinion, they look fine. But I didn't find
> negative tests, where we need to wrap a Var with PHV like the following:
Pushed after adding tw
On 12/2/24 10:46, Richard Guo wrote:
On Wed, Nov 27, 2024 at 5:45 PM Richard Guo wrote:
I ended up using 'under the same lowest nulling outer join' to
keep consistent with the wording used elsewhere. Please see the
updated patch attached.
Commit e032e4c7d computes the nullingrel data for eac
On Wed, Nov 27, 2024 at 5:45 PM Richard Guo wrote:
> I ended up using 'under the same lowest nulling outer join' to
> keep consistent with the wording used elsewhere. Please see the
> updated patch attached.
Commit e032e4c7d computes the nullingrel data for each leaf RTE, and
we can leverage tha
Hi Richard
> BTW, since commit cb8e50a4a, we've chosen not to wrap a non-var
> expression if it contains Vars/PHVs of the pulled-up subquery and does
> not contain non-strict constructs. I wonder if we can apply the same
> optimization from this patch to non-var expressions: for a LATERAL
> subqu
On Fri, Nov 22, 2024 at 5:08 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> The patch looks good to me, the implementation is concise and clear. I can't
> imagine any visible overhead due to storing lowest_nullable_relids in this
> context. The only nitpick I have is about this commentary:
>
>
> On Fri, Jun 21, 2024 at 10:35:30AM GMT, Richard Guo wrote:
> On Mon, Jan 15, 2024 at 1:50 PM Richard Guo wrote:
> > Updated this patch over 29f114b6ff, which indicates that we should apply
> > the same rules for PHVs.
>
> Here is a new rebase of this patch, with some tweaks to comments. I've
>
On Mon, Jan 15, 2024 at 1:50 PM Richard Guo wrote:
> Updated this patch over 29f114b6ff, which indicates that we should apply
> the same rules for PHVs.
Here is a new rebase of this patch, with some tweaks to comments. I've
also updated the commit message to better explain the context.
To recap
Updated this patch over 29f114b6ff, which indicates that we should apply
the same rules for PHVs.
Thanks
Richard
v3-0001-Avoid-unnecessary-PlaceHolderVars-for-Vars-PHVs.patch
Description: Binary data
On Fri, Jun 2, 2023 at 1:33 AM James Coleman wrote:
> On Wed, May 31, 2023 at 10:30 PM Richard Guo
> wrote:
> > Thanks for the review!
>
> Sure thing!
I've updated the patch according to the reviews as attached. But I did
not add ORDER BY clause in the test, as we don't need it for correctnes
On Wed, May 31, 2023 at 10:30 PM Richard Guo wrote:
>
>
> On Wed, May 31, 2023 at 1:27 AM James Coleman wrote:
>>
>> This looks good to me.
>
>
> Thanks for the review!
Sure thing!
>>
>> A few small tweaks suggested to comment wording:
>>
>> +-- lateral reference for simple Var can escape Place
On Wed, May 31, 2023 at 1:27 AM James Coleman wrote:
> This looks good to me.
Thanks for the review!
> A few small tweaks suggested to comment wording:
>
> +-- lateral reference for simple Var can escape PlaceHolderVar if the
> +-- referenced rel is under the same lowest nulling outer join
>
On Fri, May 12, 2023 at 2:35 AM Richard Guo wrote:
>
> I happened to notice that the query below can be inefficient.
>
> # explain (costs off)
> select * from
> int8_tbl a left join
> (int8_tbl b inner join
>lateral (select *, b.q2 as x from int8_tbl c) ss on b.q2 = ss.q1)
> on a.q1 = b.
I happened to notice that the query below can be inefficient.
# explain (costs off)
select * from
int8_tbl a left join
(int8_tbl b inner join
lateral (select *, b.q2 as x from int8_tbl c) ss on b.q2 = ss.q1)
on a.q1 = b.q1;
QUERY PLAN
Has
13 matches
Mail list logo
