ú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 o
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 SPI_execute_plan_e
č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
> conta
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 a/doc/src/sgml/spi.s
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 GetCachedPl
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 use
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
+++ b/src/backend/comm
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,
entry->plansou
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
call-graph-profile
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, OU
10 matches
Mail list logo
