Michel Pelletier writes:
> On Sun, Oct 20, 2024 at 10:13 AM Tom Lane wrote:
>> But it seems like we could get an easy win by adjusting
>> plpgsql_exec_function along the lines of
>> ...
> I tried this change and couldn't get it to work, on the next line:
> if (VARATT_IS_EXTERNAL_EXPANDED_RW(
On Sun, Oct 20, 2024 at 10:13 AM Tom Lane wrote:
>
> I'm not sure. It seems certain that if the object is already expanded
> (either R/W or R/O), the paths for that in plpgsql_exec_function could
> be taken regardless of its specific type.
>
> But it seems like we could get an easy win by adju
Michel Pelletier writes:
> On Sun, Oct 20, 2024 at 10:13 AM Tom Lane wrote:
>> The other problem is that plpgsql only knows how to do such expansion
>> for arrays, and it's not obvious how to extend that part.
> Perhaps a third member function for ExpandedObjectMethods that formalizes
> the expa
On Sun, Oct 20, 2024 at 10:13 AM Tom Lane wrote:
> Michel Pelletier writes:
> > I found this thread from the original path implementation from Tom Lane
> in
>
> >> appropriate APIs is left as a task for future work.
>
> Yeah, we thought that it wouldn't be appropriate to try to design
> general
Michel Pelletier writes:
> I found this thread from the original path implementation from Tom Lane in
> 2015:
> https://www.postgresql.org/message-id/E1Ysvgz-s0-DP%40gemulon.postgresql.org
>> In this initial implementation, a few heuristics have been hard-wired
>> into plpgsql to improve perfo
Hello!
I'm working on the OneSparse Postgres extension that wraps the GraphBLAS
API with a SQL interface for doing graph analytics and other sparse linear
algebra operations:
https://onesparse.github.io/OneSparse/test_matrix_header/
OneSparse wraps the GraphBLAS opaque handles in Expanded Object
