Re: Using Expanded Objects other than Arrays from plpgsql

On Fri, Nov 1, 2024 at 5:53 PM Michel Pelletier <pelletier(dot)michel(at)gmail(dot)com>
wrote:

> On Fri, Nov 1, 2024 at 3:27 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Michel Pelletier <pelletier(dot)michel(at)gmail(dot)com> writes:
>>
>> Here is a v1 patch series that does the first part of what we've been
>> talking about, which is to implement the new optimization rule for
>> the case of a single RHS reference to the target variable. I'm
>> curious to know if it helps you at all by itself. You'll definitely
>> also need commit 534d0ea6c, so probably applying these on our git
>> master branch would be the place to start.
>>
>
> I'll apply these tonight and get back to you asap. There are many
> functions in my API that take only one expanded RHS argument, so I'll look
> for some cases where your changes reduce expansions when I run my tests.
>

I tested these patches with my test setup and can confirm there is now one
less expansion in this function:

create or replace function test_expand(graph matrix) returns matrix
language plpgsql as
$$
declare
nvals bigint = nvals(graph);
begin
return graph;
end;
$$;

postgres=# select test_expand(a) from test_fixture ;
DEBUG: matrix_nvals
DEBUG: DatumGetMatrix
DEBUG: expand_matrix
DEBUG: new_matrix
DEBUG: context_callback_matrix_free
DEBUG: matrix_out
DEBUG: DatumGetMatrix
DEBUG: expand_matrix
DEBUG: new_matrix
DEBUG: context_callback_matrix_free

The second expansion in matrix_out happens outside the function, so inside
there is only the one expansion for both matrix_nvals and the assignment.
Thank you! All my tests continue to pass and the change seems to work well.

Looking forward to helping test the support function idea, let me know if
there's anything else I can do to validate the idea.

-Michel

>