Michel Pelletier <pelletier.mic...@gmail.com> writes:
> On Wed, Dec 18, 2024 at 12:22 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
>> So, just to clarify where we're at: you are satisfied that the current
>> patch-set does what you need?
> There are a few cases where I have to force an expansion, I work around
> this by calling a `wait()` function, which expands the datum, calls
> GrB_wait() on it (a nop in this case) and returns a r/w pointer. You can
> see this in the following Triangle Counting function which is a matrix
> multiplication of a graph to itself, using itself as a mask. This matrix
> reduces to the triangle count (times six):
> create or replace function tcount_b(graph matrix) returns bigint language
> plpgsql as
> $$
> begin
> graph = wait(graph);
> graph = mxm(graph, graph, 'plus_pair_int32', mask=>graph,
> descr=>'s');
> return reduce_scalar(graph) / 6;
> end;
> $$;
> ...
> I agree it makes sense to have more use cases before making deeper
> changes. I only work with expanded forms, but need to call wait() to
> pre-expand the object to avoid multiple expansions in functions that can
> take the same object in multiple parameters.
Hmm. I agree that the wait() call is a bit ugly, but there are at
least two things that seem worth looking into before we go so far
as inventing type-support infrastructure:
1. Why isn't the incoming "graph" object already expanded? It
often would be read-only, but that seems like it might be enough
given your description of GraphBLAS' behavior.
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? It would be messier than just blindly
applying DatumGetWhatever() to each parameter position; but with a
bit of thought I bet you could create some support logic that would
hide most of the mess.
regards, tom lane
