public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Michel Pelletier <[email protected]>
Cc: pgsql-general <[email protected]>
Subject: Re: Using Expanded Objects other than Arrays from plpgsql
Date: Sun, 20 Oct 2024 13:13:31 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CACxu=vJaKFNsYxooSnW1wEgsAO5u_v1XYBacfVJ14wgJV_PYeg@mail.gmail.com>
References: <CACxu=vJaKFNsYxooSnW1wEgsAO5u_v1XYBacfVJ14wgJV_PYeg@mail.gmail.com>

Michel Pelletier <[email protected]> writes:
> I found this thread from the original path implementation from Tom Lane in
> 2015:
> https://www.postgresql.org/message-id/E1Ysvgz-0000s0-DP%40gemulon.postgresql.org
>> In this initial implementation, a few heuristics have been hard-wired
>> into plpgsql to improve performance for arrays that are stored in
>> plpgsql variables. We would like to generalize those hacks so that
>> other datatypes can obtain similar improvements, but figuring out some
>> 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.

> 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?

> 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.  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 other problem is that plpgsql only knows how to do such expansion
for arrays, and it's not obvious how to extend that part.

But it seems like we could get an easy win by adjusting
plpgsql_exec_function along the lines of

l. 549:
-                    if (!var->isnull && var->datatype->typisarray)
+                    if (!var->isnull)

l. 564:
-                        else
+                        else if (var->datatype->typisarray)

How far does that improve matters for you?

The comment above line 549 cross-references exec_assign_value,
but it looks like that's already set up to be similarly type-agnostic
about values that are already expanded.

			regards, tom lane

view thread (2+ messages)  latest in thread

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: <[email protected]>

* 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