Re: Using Expanded Objects other than Arrays from plpgsql - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: Using Expanded Objects other than Arrays from plpgsql
Date
Msg-id 0AC229FA-A3F1-43FD-B0DC-A46A73FEAFF7@yandex-team.ru
Whole thread Raw
In response to Re: Using Expanded Objects other than Arrays from plpgsql  (Michel Pelletier <pelletier.michel@gmail.com>)
Responses Re: Using Expanded Objects other than Arrays from plpgsql
List pgsql-hackers
Hello everyone in this thread.

> On 21 Jan 2025, at 23:12, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> somebody will review this

I'm trying to dig into the patch set. My knowledge of the module is shallow and I hope to improve it by reading more
patchesin this area. 

This patch set provides a new test, which runs just fine without the patch. But it's somewhat expected, such
optimizationsmust be transparent for user... 

And the coverage of newly invented mark_stmt() 42.37%. Some of branches are easy noops, but some are not.
I assume as a granted that we will not every get into infinite loop in a recursive call of mark_stmt().

expr_is_assignment_source() is named like if it should return nool, but it's void.

I could not grasp from reading the code one generic question about new optimization rule. What cost does checking for
possiblein-place update incurs to code cannot have this optimization? Is it O(numer_of_arguments) of for every
assignmentexecution? 

Thanks!


Best regards, Andrey Borodin.


pgsql-hackers by date:

Previous
From: Jacob Brazeal
Date:
Subject: Re: MAX_BACKENDS size (comment accuracy)
Next
From: Peter Eisentraut
Date:
Subject: Re: Convert sepgsql tests to TAP