public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michel Pelletier <[email protected]>
To: Tom Lane <[email protected]>
Cc: pgsql-general <[email protected]>
Subject: Re: Using Expanded Objects other than Arrays from plpgsql
Date: Sun, 20 Oct 2024 11:25:30 -0700
Message-ID: <CACxu=vLE1AWwz4cQGv-moKGOCYQrXyMhxBX_myBOyK42mrx2BA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CACxu=vJaKFNsYxooSnW1wEgsAO5u_v1XYBacfVJ14wgJV_PYeg@mail.gmail.com>
<[email protected]>
On Sun, Oct 20, 2024 at 10:13 AM Tom Lane <[email protected]> wrote:
> Michel Pelletier <[email protected]> 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 APIs till we had more kinds of expandable objects. Maybe
> now is a good time to push forward on that.
>
Great, I'm happy to be involved!
> My first thought was to add a flag to CREATE TYPE like "EXPANDED = true"
> or
> > some other better name that indicates that the object can be safely taken
> > ownership of in its expanded state and not copied.
>
> Isn't that inherent in the notion of R/W vs R/O expanded-object
> pointers?
>
I'm not sure I'm qualified enough to agree with you but I see your point.
> > And then there is just removing the existing restriction on arrays only.
> > Is any other expanded object out there really interested in being
> > flattened/expanded over and over again?
>
> 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.
Agreed.
> The thing that is debatable
> is "if the object is in a flat state, should we forcibly expand it
> here?". That could be a win if the function later does object
> accesses that would benefit --- but it might never do so. We chose
> to always expand arrays, and we've gotten little pushback on that,
> but the tradeoffs might be different for other sorts of expanded
> objects.
>
The OneSparse objects will always expand themselves on first use via a
DatumGetExpandedArray like macro wrapper, there is no run-time benefit to
their flat representation, so I'm fine with not forcing their expansion
ahead of time, but once I expand it I'd like it to stay expanded until the
function returns (as much as possible) the serialization costs for very
large sparse matrices is heavy.
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 expansion interface like found in DatumGetExpandedArray? I closely
follow that same pattern in my code.
>
> But it seems like we could get an easy win by adjusting
> plpgsql_exec_function along the lines of
> ...
>
> How far does that improve matters for you?
>
I'll give it a try in my local benchmarking code and get back to you, thank
you for the fast reply and the insight!
-Michel
view thread (2+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Using Expanded Objects other than Arrays from plpgsql
In-Reply-To: <CACxu=vLE1AWwz4cQGv-moKGOCYQrXyMhxBX_myBOyK42mrx2BA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox