Horton

Re: Using Expanded Objects other than Arrays from plpgsql

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michel Pelletier <pelletier.michel@gmail.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2024-12-27T00:32:11Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Allow extension functions to participate in in-place updates.

  2. Implement new optimization rule for updates of expanded variables.

  3. Detect whether plpgsql assignment targets are "local" variables.

  4. Preliminary refactoring of plpgsql expression construction.

  5. Refactor pl_funcs.c to provide a usage-independent tree walker.

  6. Generalize plpgsql's heuristic for importing expanded objects.

Michel Pelletier <pelletier.michel@gmail.com> writes:
> On Mon, Dec 23, 2024 at 8:26 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 2. If the problem is primarily with passing the same object to
>> multiple parameters of a function, couldn't you detect and optimize
>> that within the function?

> Ah that's a great idea, and it works beautifully!  Now I can do an
> efficient triangle count without even needing a function, see below
> expand_matrix is only called once:

Nice!

> That pretty much resolves my main issues.  I'm still in an exploratory
> phase but I think this gets me pretty far.  Is this something that has to
> wait for 18 to be released?  Also do you need any further testing or code
> reviewing from me?

Yeah, this is not the kind of change we would back-patch, so it'll
have to wait for v18 (or later if people are slow to review it :-( ).

I don't think there's anything more we need from you, though of course
you should keep working on your code and report back if you hit
anything that needs further improvement on our end.

			regards, tom lane