Kyotaro Horiguchi writes:
> At Fri, 22 Nov 2019 08:08:24 +0100, Pavel Stehule
> wrote in
>> a) we allow to call volatile functions from nonvolatile (stable, immutable)
>> that really does write
>> b) but this change is not visible in parent nonvolatile functions. Is
>> visible only in volatile
At Fri, 22 Nov 2019 08:08:24 +0100, Pavel Stehule
wrote in
> pá 22. 11. 2019 v 7:33 odesílatel Kyotaro Horiguchi
> napsal:
>
> > At Fri, 22 Nov 2019 06:15:25 +0100, Pavel Stehule
> > wrote in
> > > čt 21. 11. 2019 v 20:44 odesílatel Tom Lane napsal:
> > >
> > > > Pavel Stehule writes:
> >
On 22.11.2019 11:05, Pavel Stehule wrote:
We should to distinguish between bad result and not well optimized plan.
If it is not possible to implement runtime check tha timmutable function
is not making any changes in database.
Please notice, that even right now without any get snapshot
pá 22. 11. 2019 v 8:32 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 22.11.2019 10:08, Pavel Stehule wrote:
>
>
> I test it, and there is a problem already. We doesn't raise a exception,
> but the result is wrong
>
>
> create table foo(a int);
>
> create or replace
On 22.11.2019 10:08, Pavel Stehule wrote:
I test it, and there is a problem already. We doesn't raise a
exception, but the result is wrong
create table foo(a int);
create or replace function f1(int)
returns void as $$
begin
insert into foo values($1);
end;
$$ language plpgsql;
create
pá 22. 11. 2019 v 7:33 odesílatel Kyotaro Horiguchi
napsal:
> At Fri, 22 Nov 2019 06:15:25 +0100, Pavel Stehule
> wrote in
> > čt 21. 11. 2019 v 20:44 odesílatel Tom Lane napsal:
> >
> > > Pavel Stehule writes:
> > > > čt 21. 11. 2019 v 10:31 odesílatel Konstantin Knizhnik <
> > > >
At Fri, 22 Nov 2019 06:15:25 +0100, Pavel Stehule
wrote in
> čt 21. 11. 2019 v 20:44 odesílatel Tom Lane napsal:
>
> > Pavel Stehule writes:
> > > čt 21. 11. 2019 v 10:31 odesílatel Konstantin Knizhnik <
> > > k.knizh...@postgrespro.ru> napsal:
> > >> With contain_mutable_functions the patch
čt 21. 11. 2019 v 20:44 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > čt 21. 11. 2019 v 10:31 odesílatel Konstantin Knizhnik <
> > k.knizh...@postgrespro.ru> napsal:
> >> With contain_mutable_functions the patch becomes trivial.
>
> > Stable functions doesn't need own snapshot too, so
Pavel Stehule writes:
> čt 21. 11. 2019 v 10:31 odesílatel Konstantin Knizhnik <
> k.knizh...@postgrespro.ru> napsal:
>> With contain_mutable_functions the patch becomes trivial.
> Stable functions doesn't need own snapshot too, so it is not fully correct,
> but it is on safe side.
No, I doubt
čt 21. 11. 2019 v 10:31 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
> > I've set the CF entry to "Waiting on Author" pending a new patch
> > that does it like that.
>
> With contain_mutable_functions the patch becomes trivial.
>
Stable functions doesn't need own
I've set the CF entry to "Waiting on Author" pending a new patch
that does it like that.
With contain_mutable_functions the patch becomes trivial.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/src/pl/plpgsql/src/pl_exec.c
Kyotaro Horiguchi writes:
> At Tue, 12 Nov 2019 11:27:24 +0300, Konstantin Knizhnik
> wrote in
>> In my opinion contain_mutable_functions() is the best solution.
>> But if it is not acceptable, I will rewrite the patch in white-list
>> fashion.
> I agree for just relying on
At Tue, 12 Nov 2019 11:27:24 +0300, Konstantin Knizhnik
wrote in
>
>
> On 11.11.2019 20:22, Tom Lane wrote:
> >
> > None of those statements are true, in my experience.
> >
> > In general, this patch seems like it's learned nothing from our
> > experiences with the late and unlamented
On 11.11.2019 20:22, Tom Lane wrote:
None of those statements are true, in my experience.
In general, this patch seems like it's learned nothing from our
experiences with the late and unlamented exec_simple_check_node()
(cf commit 00418c612). Having a piece of plpgsql that has to know
Konstantin Knizhnik writes:
>> čt 7. 11. 2019 v 13:03 odesílatel Kyotaro Horiguchi
>> mailto:horikyota@gmail.com>> napsal:
>>> I might be too worrying, but maybe we should write the function in
>>> white-listed way, that is, expr_needs_snapshot returns false only if
>>> the whole tree
pá 8. 11. 2019 v 14:31 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 07.11.2019 15:09, Pavel Stehule wrote:
>
>
>
> čt 7. 11. 2019 v 13:03 odesílatel Kyotaro Horiguchi <
> horikyota@gmail.com> napsal:
>
>> Hello.
>>
>> At Tue, 5 Nov 2019 22:14:40 +0100, Pavel
On 07.11.2019 15:09, Pavel Stehule wrote:
čt 7. 11. 2019 v 13:03 odesílatel Kyotaro Horiguchi
mailto:horikyota@gmail.com>> napsal:
Hello.
At Tue, 5 Nov 2019 22:14:40 +0100, Pavel Stehule
mailto:pavel.steh...@gmail.com>> wrote in
> Hi
>
> pá 23. 8. 2019 v 16:32
čt 7. 11. 2019 v 13:03 odesílatel Kyotaro Horiguchi
napsal:
> Hello.
>
> At Tue, 5 Nov 2019 22:14:40 +0100, Pavel Stehule
> wrote in
> > Hi
> >
> > pá 23. 8. 2019 v 16:32 odesílatel Konstantin Knizhnik <
> > k.knizh...@postgrespro.ru> napsal:
> >
> > >
> > >
> > > On 23.08.2019 14:42, Pavel
Hello.
At Tue, 5 Nov 2019 22:14:40 +0100, Pavel Stehule
wrote in
> Hi
>
> pá 23. 8. 2019 v 16:32 odesílatel Konstantin Knizhnik <
> k.knizh...@postgrespro.ru> napsal:
>
> >
> >
> > On 23.08.2019 14:42, Pavel Stehule wrote:
> >
> >
> > In reality it is not IMMUTABLE function. On second hand,
Hi
pá 23. 8. 2019 v 16:32 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 23.08.2019 14:42, Pavel Stehule wrote:
>
>
> In reality it is not IMMUTABLE function. On second hand, there are lot of
> application that depends on this behave.
>
> It is well know trick how
Hi
I testing very simple function
create or replace function f1(int) returns int as $$ declare i int = 0;
begin while i < $1 loop i = i + 1; end loop; return i; end $$ language
plpgsql immutable;
profile - when function is marked as immutable
8,65% postgres[.] ExecInterpExpr
On 13.09.2019 10:16, Pavel Stehule wrote:
pá 13. 9. 2019 v 9:09 odesílatel Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> napsal:
On 24.08.2019 19:13, Pavel Stehule wrote:
so 24. 8. 2019 v 18:01 odesílatel David Fetter mailto:da...@fetter.org>> napsal:
On
pá 13. 9. 2019 v 9:09 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 24.08.2019 19:13, Pavel Stehule wrote:
>
>
>
> so 24. 8. 2019 v 18:01 odesílatel David Fetter napsal:
>
>> On Fri, Aug 23, 2019 at 11:10:28AM +0200, Pavel Stehule wrote:
>> > pá 23. 8. 2019 v 11:05
On Sat, Aug 24, 2019 at 12:01 PM David Fetter wrote:
> No, it's lying to the RDBMS, so it's pilot error. The problem of
> determining from the function itself whether it is in fact immutable
> is, in general, equivalent to the Halting Problem, so no, we can't
> figure it out. We do need to trust
so 24. 8. 2019 v 18:01 odesílatel David Fetter napsal:
> On Fri, Aug 23, 2019 at 11:10:28AM +0200, Pavel Stehule wrote:
> > pá 23. 8. 2019 v 11:05 odesílatel Konstantin Knizhnik <
> > k.knizh...@postgrespro.ru> napsal:
> >
> > >
> > >
> > > On 22.08.2019 18:56, Pavel Stehule wrote:
> > >
> > >
>
On Fri, Aug 23, 2019 at 11:10:28AM +0200, Pavel Stehule wrote:
> pá 23. 8. 2019 v 11:05 odesílatel Konstantin Knizhnik <
> k.knizh...@postgrespro.ru> napsal:
>
> >
> >
> > On 22.08.2019 18:56, Pavel Stehule wrote:
> >
> >
> >
> > čt 22. 8. 2019 v 17:51 odesílatel Konstantin Knizhnik <
> >
On 23.08.2019 14:42, Pavel Stehule wrote:
In reality it is not IMMUTABLE function. On second hand, there are lot
of application that depends on this behave.
It is well know trick how to reduce estimation errors related to
JOINs. When immutable function has constant parameters, then it is
pá 23. 8. 2019 v 13:21 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 23.08.2019 12:10, Pavel Stehule wrote:
>
>
>
> pá 23. 8. 2019 v 11:05 odesílatel Konstantin Knizhnik <
> k.knizh...@postgrespro.ru> napsal:
>
>>
>>
>> On 22.08.2019 18:56, Pavel Stehule wrote:
>>
On 23.08.2019 12:10, Pavel Stehule wrote:
pá 23. 8. 2019 v 11:05 odesílatel Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> napsal:
On 22.08.2019 18:56, Pavel Stehule wrote:
čt 22. 8. 2019 v 17:51 odesílatel Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>>
pá 23. 8. 2019 v 11:05 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 22.08.2019 18:56, Pavel Stehule wrote:
>
>
>
> čt 22. 8. 2019 v 17:51 odesílatel Konstantin Knizhnik <
> k.knizh...@postgrespro.ru> napsal:
>
>> Some more information...
>> First of all I found out
On 22.08.2019 18:56, Pavel Stehule wrote:
čt 22. 8. 2019 v 17:51 odesílatel Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> napsal:
Some more information...
First of all I found out that marking PL/pgSQL function as
immutable significantly increase speed of its
čt 22. 8. 2019 v 17:51 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
> Some more information...
> First of all I found out that marking PL/pgSQL function as immutable
> significantly increase speed of its execution:
> 19808 ms vs. 27594. It happens because
Some more information...
First of all I found out that marking PL/pgSQL function as immutable
significantly increase speed of its execution:
19808 ms vs. 27594. It happens because exec_eval_simple_expr is taken
snapshot if function is volatile (default).
I wonder if PL/pgSQL compiler can detect
On 22.08.2019 3:27, Tsunakawa, Takayuki wrote:
From: Konstantin Knizhnik [mailto:k.knizh...@postgrespro.ru]
PL/pgSQL: 29044.361 ms
C/SPI: 22785.597 ms
The fact that difference between PL/pgSQL and function implemented in C
using SPI is not so large was expected by me.
This
On 22.08.2019 5:40, Kyotaro Horiguchi wrote:
Hello.
At Wed, 21 Aug 2019 19:41:08 +0300, Konstantin Knizhnik
wrote in
Hi, hackers.
One of our customers complains about slow execution of PL/pgSQL
functions comparing with Oracle.
So he wants to compile PL/pgSQL functions (most likely
Hello.
At Wed, 21 Aug 2019 19:41:08 +0300, Konstantin Knizhnik
wrote in
> Hi, hackers.
>
> One of our customers complains about slow execution of PL/pgSQL
> functions comparing with Oracle.
> So he wants to compile PL/pgSQL functions (most likely just-in-time
> compilation).
> Certainly
From: Konstantin Knizhnik [mailto:k.knizh...@postgrespro.ru]
> PL/pgSQL: 29044.361 ms
> C/SPI: 22785.597 ms
>
> The fact that difference between PL/pgSQL and function implemented in C
> using SPI is not so large was expected by me.
This PL/pgSQL overhead is not so significant
37 matches
Mail list logo
