Horton

Re: Using Expanded Objects other than Arrays from plpgsql

Michel Pelletier <pelletier.michel@gmail.com>

View thread
From: Michel Pelletier <pelletier.michel@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pavel Stehule <pavel.stehule@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2024-12-25T20:25:18Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Allow extension functions to participate in in-place updates.

  2. Implement new optimization rule for updates of expanded variables.

  3. Detect whether plpgsql assignment targets are "local" variables.

  4. Preliminary refactoring of plpgsql expression construction.

  5. Refactor pl_funcs.c to provide a usage-independent tree walker.

  6. Generalize plpgsql's heuristic for importing expanded objects.

On Mon, Dec 23, 2024 at 8:26 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Michel Pelletier <pelletier.michel@gmail.com> writes:
> > ...
> > 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:
>

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

Ah that's a great idea, and it works beautifully!  Now I can do an
efficient triangle count without even needing a function, see below
expand_matrix is only called once:

postgres=# select reduce_scalar(mxm(graph, graph, mask=>graph, c=>graph)) /
6 as tcount from vlivejournals ;
DEBUG:  matrix_mxm
DEBUG:  DatumGetMatrix
DEBUG:  expand_matrix   -- only called once!
DEBUG:  new_matrix
DEBUG:  DatumGetMatrixMaybeA
DEBUG:  DatumGetMatrixMaybeAB
DEBUG:  DatumGetMatrixMaybeABC
DEBUG:  matrix_reduce_scalar
DEBUG:  DatumGetMatrix
DEBUG:  new_scalar
DEBUG:  scalar_div_int32
DEBUG:  new_scalar
DEBUG:  scalar_out
┌─────────────────┐
│     tcount      │
├─────────────────┤
│ int32:177820130 │
└─────────────────┘

What a wonderful Christmas present to me, thank you Tom!

That pretty much resolves my main issues.  I'm still in an exploratory
phase but I think this gets me pretty far.  Is this something that has to
wait for 18 to be released?  Also do you need any further testing or code
reviewing from me?

-Michel