On Tue, 11 Feb 2025 at 21:50, Tom Lane wrote:
>
> Andrey Borodin writes:
> > On 7 Feb 2025, at 02:05, Tom Lane wrote:
> >> Do you have any further comments on this patch?
>
> > No, all steps of the patch set look good to me.
>
> Pushed then. Thanks for reviewing!
Thanks to Michel and everyone w
Andrey Borodin writes:
> On 7 Feb 2025, at 02:05, Tom Lane wrote:
>> Do you have any further comments on this patch?
> No, all steps of the patch set look good to me.
Pushed then. Thanks for reviewing!
regards, tom lane
> On 7 Feb 2025, at 02:05, Tom Lane wrote:
>
> Do you have any further comments on this patch?
No, all steps of the patch set look good to me.
Best regards, Andrey Borodin.
Andrey Borodin writes:
> I've found 1 users on Github [0]. And a lot of copied code like [1]. And
> there might be some unindexed cases.
> Let's keep paramarg2.
Yeah, sounds like the best path if there are already outside users
of paramarg.
Do you have any further comments on this patch?
Hi, Tom!
On Mon, 3 Feb 2025 at 21:53, Tom Lane wrote:
>
> Pavel Borisov writes:
> > Minor notes on the patches:
>
> > If dump_* functions could use the newly added walker, the code would
> > look better. I suppose the main complication is that dump_* functions
> > contain a lot of per-statement
> On 3 Feb 2025, at 23:18, Tom Lane wrote:
>
> But I don't want to think of
> EEOP_PARAM_CALLBACK as being specifically tied to PL/pgSQL.
I've found 1 users on Github [0]. And a lot of copied code like [1]. And there
might be some unindexed cases.
Let's keep paramarg2.
Best regards, Andrey
I wrote:
> Admittedly this is all moot unless some other extension starts
> using EEOP_PARAM_CALLBACK, and I didn't find any evidence of that
> using Debian Code Search. But I don't want to think of
> EEOP_PARAM_CALLBACK as being specifically tied to PL/pgSQL.
However ... given that I failed to f
Andrey Borodin writes:
>> On 3 Feb 2025, at 22:36, Tom Lane wrote:
>> I'm not wedded to that name; do you have a better idea?
> I'd propose something like attached. But feel free to ignore my suggestion: I
> do not understand context of these structure members.
Hmm, you're suggesting naming th
> On 3 Feb 2025, at 22:36, Tom Lane wrote:
>
> I'm not wedded to that name; do you have a better idea?
I'd propose something like attached. But feel free to ignore my suggestion: I
do not understand context of these structure members.
Best regards, Andrey Borodin.
rename.diff
Description:
Pavel Borisov writes:
> Minor notes on the patches:
> If dump_* functions could use the newly added walker, the code would
> look better. I suppose the main complication is that dump_* functions
> contain a lot of per-statement prints/formatting. So maybe a way to
> implement this is to put these
Andrey Borodin writes:
> (Well, maybe paramarg2 resonates a bit, just from similarity with varchar2)
I'm not wedded to that name; do you have a better idea?
Another idea could be to make it an array:
-void *paramarg;/* private data for same */
+void *para
Hi, Tom
On Mon, 3 Feb 2025 at 07:02, Michel Pelletier
wrote:
>
> On Sun, Feb 2, 2025 at 1:57 PM Tom Lane wrote:
>>
>> I wrote:
>> > Hmm, it seemed to still apply for me. But anyway, I needed to make
>> > the other changes, so here's v4.
>>
>> PFA v5. The new 0001 patch refactors the free_xxx i
> On 3 Feb 2025, at 02:56, Tom Lane wrote:
>
> I decided to see what would happen if we tried to avoid the code
> duplication in pl_funcs.c by making some "walker" infrastructure
> akin to expression_tree_walker. While that doesn't seem useful
> for the dump_xxx functions, it works very nicel
On Sun, Feb 2, 2025 at 1:57 PM Tom Lane wrote:
> I wrote:
> > Hmm, it seemed to still apply for me. But anyway, I needed to make
> > the other changes, so here's v4.
>
> PFA v5. The new 0001 patch refactors the free_xxx infrastructure
> to create plpgsql_statement_tree_walker(), and then in wha
I wrote:
> Hmm, it seemed to still apply for me. But anyway, I needed to make
> the other changes, so here's v4.
I decided to see what would happen if we tried to avoid the code
duplication in pl_funcs.c by making some "walker" infrastructure
akin to expression_tree_walker. While that doesn't se
Pavel Borisov writes:
> I started looking at the patchset.
> Recently it got conflicts with changes to yyparse (473a575e05979b4db).
> Could you rebase it and also do naming changes proposed by Andrew
> Borodin, which I definitely agree with?
Hmm, it seemed to still apply for me. But anyway, I ne
Hi, Michel and Tom!
On Sun, 26 Jan 2025 at 23:04, Tom Lane wrote:
>
> Andrey Borodin writes:
> > On 26 Jan 2025, at 20:37, Tom Lane wrote:
> >> Maybe we should recast it as an action. What do you think of
> >> "mark_expr_as_assignment_source"?
>
> > Sounds better to me. I found no examples of
Andrey Borodin writes:
> On 26 Jan 2025, at 20:37, Tom Lane wrote:
>> Maybe we should recast it as an action. What do you think of
>> "mark_expr_as_assignment_source"?
> Sounds better to me. I found no examples of similar functions nether in
> pl_gram.y, nor in gram.y, so IMO mark_expr_as_assi
> On 26 Jan 2025, at 20:37, Tom Lane wrote:
>
>> And the coverage of newly invented mark_stmt() 42.37%. Some of branches are
>> easy noops, but some are not.
>
> Yeah. I'm not too concerned about that because it's pretty much a
> copy-and-paste of the adjacent code. Maybe we should think a
Andrey Borodin writes:
>> On 21 Jan 2025, at 23:12, Tom Lane wrote:
>> somebody will review this
> I'm trying to dig into the patch set. My knowledge of the module is shallow
> and I hope to improve it by reading more patches in this area.
Thanks for looking!
> And the coverage of newly inven
Hello everyone in this thread.
> On 21 Jan 2025, at 23:12, Tom Lane wrote:
>
> somebody will review this
I'm trying to dig into the patch set. My knowledge of the module is shallow and
I hope to improve it by reading more patches in this area.
This patch set provides a new test, which runs ju
Michel Pelletier writes:
> Thanks Tom! These applied cleanly to my test env and actually increased my
> livejournal graph benchmark by a million edges per second, so I guess I
> didn't have all the previous changes in my last build as you noted.
Nice! I hope somebody will review this, because I
On Wed, Jan 15, 2025 at 10:09 AM Tom Lane wrote:
> I noticed that v2 of this patch series failed to apply after
> 7b27f5fd3, so here's v3. No non-trivial changes.
>
Thanks Tom! These applied cleanly to my test env and actually increased my
livejournal graph benchmark by a million edges per sec
I noticed that v2 of this patch series failed to apply after
7b27f5fd3, so here's v3. No non-trivial changes.
regards, tom lane
From d82b50dc222fb8751f45875fb3627bf08ca2e0cf Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Wed, 15 Jan 2025 12:37:54 -0500
Subject: [PATCH v3
On Sat, Jan 4, 2025 at 11:35 AM Tom Lane wrote:
> Michel Pelletier writes:
> > I've circled back on this task to do some work improving the skeleton
> code,
> > but going back through our thread I landed on this point Tom made about
> > usefulness vs pure skeleton and my natural desire is to mak
Michel Pelletier writes:
> I've circled back on this task to do some work improving the skeleton code,
> but going back through our thread I landed on this point Tom made about
> usefulness vs pure skeleton and my natural desire is to make a simple
> expanded object that is also useful, so I brain
On Tue, Nov 19, 2024 at 11:45 AM Tom Lane wrote:
> Pavel Stehule writes:
> > út 19. 11. 2024 v 18:51 odesílatel Michel Pelletier <
> > pelletier.mic...@gmail.com> napsal:
> >> A couple years ago I tried to compress what I learned about expanded
> >> objects into a dummy extension that just provi
Michel Pelletier writes:
> On Mon, Dec 23, 2024 at 8:26 AM Tom Lane wrote:
>> 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?
> Ah that's a great idea, and it works beautifully! No
On Mon, Dec 23, 2024 at 8:26 AM Tom Lane wrote:
> Michel Pelletier 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
Michel Pelletier writes:
> On Wed, Dec 18, 2024 at 12:22 PM Tom Lane 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,
On Wed, Dec 18, 2024 at 12:22 PM Tom Lane wrote:
> Michel Pelletier writes:
> > My bad, sorry for the long confusing email, I figured out that I was
> > calling the wrong macro when getting my matrix datum and inadvertently
> > expanding RO pointers as well, I've fixed that issue, and everything
Michel Pelletier writes:
> My bad, sorry for the long confusing email, I figured out that I was
> calling the wrong macro when getting my matrix datum and inadvertently
> expanding RO pointers as well, I've fixed that issue, and everything is
> working great! No extra expansions and my support fu
On Fri, Dec 6, 2024 at 4:51 PM Michel Pelletier
wrote:
>
> My question is about nvals = nvals(graph) in that function above, the
> object is flattened and then rexpanded, even after the object was expanded
> and returned by wait() [1] into a r/w pointer.
>
...
>
> mxm calls expand_matrix three
On Tue, Dec 3, 2024 at 4:42 PM Tom Lane wrote:
> Michel Pelletier writes:
> > Here's a WIP patch for a pgexpanded example in src/test/modules.
>
> I didn't look at your patch yet, but in the meantime here's an update
> that takes the next step towards what I promised.
>
Awesome! I made a suppo
Michel Pelletier writes:
> Here's a WIP patch for a pgexpanded example in src/test/modules. The
> object is very simple and starts with an integer and increments that value
> every time it is expanded. I added some regression tests that test two sql
> functions that replicate the expansion issue
Michel Pelletier writes:
> Here's a WIP patch for a pgexpanded example in src/test/modules.
I didn't look at your patch yet, but in the meantime here's an update
that takes the next step towards what I promised.
0001-0003 are the same as before, with a couple of trivial changes
to rebase them up
On Tue, Nov 19, 2024 at 12:52 PM Michel Pelletier <
pelletier.mic...@gmail.com> wrote:
> On Tue, Nov 19, 2024 at 11:45 AM Tom Lane wrote:
>
>> Pavel Stehule writes:
>> > another position can be src/test/modules - I think so your example is
>> > "similar" to plsample
>>
>> Yeah. I think we've la
út 19. 11. 2024 v 18:51 odesílatel Michel Pelletier <
pelletier.mic...@gmail.com> napsal:
>
>> So going back on the assumption I'm somehow not returning the right
>> pointer, but digging into the array code I'm pretty sure I'm following the
>> same pattern and tracing my code path is calling EOHPG
Pavel Stehule writes:
> út 19. 11. 2024 v 18:51 odesílatel Michel Pelletier <
> pelletier.mic...@gmail.com> napsal:
>> A couple years ago I tried to compress what I learned about expanded
>> objects into a dummy extension that just provides the necessary
>> boilerplate. It wasn't great but a star
On Tue, Nov 19, 2024 at 11:45 AM Tom Lane wrote:
> Pavel Stehule writes:
> > út 19. 11. 2024 v 18:51 odesílatel Michel Pelletier <
> > pelletier.mic...@gmail.com> napsal:
> >> A couple years ago I tried to compress what I learned about expanded
> >> objects into a dummy extension that just provi
>
>
> So going back on the assumption I'm somehow not returning the right
> pointer, but digging into the array code I'm pretty sure I'm following the
> same pattern and tracing my code path is calling EOHPGetRWDatum when I
> return the object, I can't get it to stop on DeleteExpandedObject, so I
>
>
> The second expansion in matrix_out happens outside the function, so inside
> there is only the one expansion for both matrix_nvals and the assignment.
> Thank you! All my tests continue to pass and the change seems to work well.
Hmm, well I spoke to soon looking at the wrong function without
On Fri, Nov 1, 2024 at 5:53 PM Michel Pelletier
wrote:
> On Fri, Nov 1, 2024 at 3:27 PM Tom Lane wrote:
>
>> Michel Pelletier writes:
>>
>> Here is a v1 patch series that does the first part of what we've been
>> talking about, which is to implement the new optimization rule for
>> the case of
On Fri, Nov 1, 2024 at 3:27 PM Tom Lane wrote:
> Michel Pelletier writes:
>
> Here is a v1 patch series that does the first part of what we've been
> talking about, which is to implement the new optimization rule for
> the case of a single RHS reference to the target variable. I'm
> curious to
On Fri, Nov 1, 2024 at 3:20 PM Tom Lane wrote:
> Michel Pelletier writes:
>
> Well, you shouldn't be using PERFORM. Not only does it not do the
> right thing, but it's not optimized for expanded objects at all:
> they'll get flattened both on the way into the statement and on
> the way out. Tr
Michel Pelletier writes:
> That all sounds great, and it sounds like my prosupport function just needs
> to return true, or set some kind of flag saying aliasing is ok. I'd like
> to help as much as possible, but some of that reparenting stuff was pretty
> deep for me, other than being a quick sa
Michel Pelletier writes:
> Here's two backtraces from gdb from this function:
> CREATE OR REPLACE FUNCTION test2(graph matrix)
> RETURNS bigint LANGUAGE plpgsql AS
> $$
> BEGIN
> perform set_element(graph, 1, 1, 1);
> RETURN nvals(graph);
> end;
> $$;
Well, you shouldn
On Thu, Oct 24, 2024 at 11:32 AM Tom Lane wrote:
> I wrote:
> > ... I'm still writing up
> > details, but right now I'm envisioning completely separate sets of
> > rules for the prosupport case versus the no-prosupport case.
>
> So here is the design I've come up with for optimizing R/W expanded
Here's two backtraces from gdb from this function:
CREATE OR REPLACE FUNCTION test2(graph matrix)
RETURNS bigint LANGUAGE plpgsql AS
$$
BEGIN
perform set_element(graph, 1, 1, 1);
RETURN nvals(graph);
end;
$$;
https://gist.githubusercontent.com/michelp/d02e3e30071044345
I wrote:
> ... I'm still writing up
> details, but right now I'm envisioning completely separate sets of
> rules for the prosupport case versus the no-prosupport case.
So here is the design I've come up with for optimizing R/W expanded
object updates in plpgsql without any special knowledge from a
Michel Pelletier writes:
> On Wed, Oct 23, 2024 at 8:21 AM Tom Lane wrote:
>> Another thing that confuses me is why there's a second flatten_matrix
>> operation happening here. Shouldn't set_element return its result
>> as a R/W expanded object?
> That confuses me too, and my default assumption
Michel Pelletier writes:
> On Wed, Oct 23, 2024 at 9:04 AM Tom Lane wrote:
>> For stuff like your vxm() function, that'd be annoying. But functions
>> that need that and are willing to deal with the aliasing hazard could
>> still provide a prosupport function that promises it's okay. What
>> we
On Wed, Oct 23, 2024 at 9:04 AM Tom Lane wrote:
> I wrote:
> > One idea I was toying with is that it doesn't matter if f()
> > throws an error so long as the plpgsql function is not executing
> > within an exception block: if the error propagates out of the plpgsql
> > function then we no longer
On Wed, Oct 23, 2024 at 8:21 AM Tom Lane wrote:
> Michel Pelletier writes:
> > Here's another example:
>
> > CREATE OR REPLACE FUNCTION test2(graph matrix)
> > RETURNS bigint LANGUAGE plpgsql AS
> > $$
> > BEGIN
> > perform set_element(graph, 1, 1, 1);
> > RETURN nvals(graph)
I wrote:
> One idea I was toying with is that it doesn't matter if f()
> throws an error so long as the plpgsql function is not executing
> within an exception block: if the error propagates out of the plpgsql
> function then we no longer care about the value of the variable.
> That would very subs
Michel Pelletier writes:
> Here's another example:
> CREATE OR REPLACE FUNCTION test2(graph matrix)
> RETURNS bigint LANGUAGE plpgsql AS
> $$
> BEGIN
> perform set_element(graph, 1, 1, 1);
> RETURN nvals(graph);
> end;
> $$;
> CREATE FUNCTION
> postgres=# select test2(
On Tue, Oct 22, 2024 at 12:33 PM Tom Lane wrote:
> Michel Pelletier writes:
> But now we also have
> expanded records, and with your use-case as an example of an extension
> trying to do similar things, I feel like we have enough examples to
> move forward.
>
Great!
As far as the hack we we
Michel Pelletier writes:
> Doing some benchmarking I noticed that when writing some simple graph
> algorithms in plpgsql, my objects were being constantly flattened and
> expanded. Posting my question above to pgsql-general Tom gave me some tips
> and suggested I move the thread here.
> My non-e
On Sun, Oct 20, 2024 at 8:46 PM Tom Lane wrote:
> Michel Pelletier writes:
> > On Sun, Oct 20, 2024 at 10:13 AM Tom Lane wrote:
>
(from thread
https://www.postgresql.org/message-id/CACxu%3DvJaKFNsYxooSnW1wEgsAO5u_v1XYBacfVJ14wgJV_PYeg%40mail.gmail.com
)
> >> But it seems like we could get an
59 matches
Mail list logo
