út 26. 1. 2021 v 4:33 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > [ plpgsql-plan-cache-for-call-3.patch ]
>
> Pushed with some additional cleanup.
>
Thank you
Pavel
> It strikes me that we ought to get rid of SPI_execute_with_receiver
> (which has been added since v13) in favor
Pavel Stehule writes:
> [ plpgsql-plan-cache-for-call-3.patch ]
Pushed with some additional cleanup.
It strikes me that we ought to get rid of SPI_execute_with_receiver
(which has been added since v13) in favor of a "SPI_execute_extended"
that shares the same options struct as
čt 21. 1. 2021 v 14:37 odesílatel Pavel Stehule
napsal:
> Hi
>
> This is a little bit of an enhanced version of the previous patch. The
> worst case overhead is reduced almost to zero. The local resource owner is
> created only when routine is executed in non-atomic mode, and when routine
>
Hi
This is a little bit of an enhanced version of the previous patch. The
worst case overhead is reduced almost to zero. The local resource owner is
created only when routine is executed in non-atomic mode, and when routine
contains a CALL statement.
Regards
Pavel
diff --git
Hi
pá 15. 1. 2021 v 22:46 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > [ plpgsql-using-local-resowner-for-call-plans-20200108.patch ]
>
> I took a quick look through this patch, just reading it without
> any testing. A few thoughts:
>
> * Instead of adding an argument to
Pavel Stehule writes:
> [ plpgsql-using-local-resowner-for-call-plans-20200108.patch ]
I took a quick look through this patch, just reading it without
any testing. A few thoughts:
* Instead of adding an argument to GetCachedPlan and ReleaseCachedPlan,
I think it'd be better to *replace* the
pá 1. 1. 2021 v 9:15 odesílatel Pavel Stehule
napsal:
> Hi
>
> only rebase
>
rebase
regards
Pavel
> Regards
>
> Pavel
>
diff --git a/src/backend/commands/prepare.c b/src/backend/commands/prepare.c
index 653ef8e41a..6f8643cc4a 100644
--- a/src/backend/commands/prepare.c
+++
Hi
only rebase
Regards
Pavel
diff --git a/src/backend/commands/prepare.c b/src/backend/commands/prepare.c
index 89087a7be3..b1d2f1af37 100644
--- a/src/backend/commands/prepare.c
+++ b/src/backend/commands/prepare.c
@@ -230,7 +230,7 @@ ExecuteQuery(ParseState *pstate,
Hi
I played with the profiler a little bit to get some data - see attached
file. Almost all overhead is related to impossibility to use simple
expression evaluation (that has very good performance now).
Probably there is no simple way to reduce this overhead.
Regards
Pavel
Hi,
here is another patch related to using CALL statement inside PL/pgSQL code.
A repeated using of CALL statement is expensive. How much?
I wrote synthetic test:
CREATE TABLE foo(a int, b int, c int);
CREATE OR REPLACE PROCEDURE public.simple_proc3(a integer, b integer, c
integer, cnt int,
10 matches
Mail list logo
