út 29. 9. 2020 v 17:20 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > I agree with these conclusions. I'll try to look if I can do #2 patch
> > better for pg14. Probably it can fix more issues related to CALL
> statement,
> > and I agree so this should not be backapatched.
>
> I've pus
Pavel Stehule writes:
> I agree with these conclusions. I'll try to look if I can do #2 patch
> better for pg14. Probably it can fix more issues related to CALL statement,
> and I agree so this should not be backapatched.
I've pushed this and marked the CF entry committed. Please start a
new th
po 28. 9. 2020 v 3:04 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > I am sending another patch that tries to allow CachedPlans for CALL
> > statements. I think this patch is very accurate, but it is not nice,
> > because it is smudging very precious reference counting for CachedPlans.
Pavel Stehule writes:
> I am sending another patch that tries to allow CachedPlans for CALL
> statements. I think this patch is very accurate, but it is not nice,
> because it is smudging very precious reference counting for CachedPlans.
I spent some time testing this. Although the #1 patch gets
On Thu, 17 Sep 2020 at 11:07, Michael Paquier wrote:
>
> On Thu, Jul 16, 2020 at 09:08:09PM +0200, Pavel Stehule wrote:
> > I am sending another patch that tries to allow CachedPlans for CALL
> > statements. I think this patch is very accurate, but it is not nice,
> > because it is smudging very p
On Thu, Jul 16, 2020 at 09:08:09PM +0200, Pavel Stehule wrote:
> I am sending another patch that tries to allow CachedPlans for CALL
> statements. I think this patch is very accurate, but it is not nice,
> because it is smudging very precious reference counting for CachedPlans.
Amit, you are regis
Hi
I am sending another patch that tries to allow CachedPlans for CALL
statements. I think this patch is very accurate, but it is not nice,
because it is smudging very precious reference counting for CachedPlans.
Current issue:
==
I found a problem with repeated CALL statements from DO c
so 11. 7. 2020 v 7:38 odesílatel Pavel Stehule
napsal:
>
>
> čt 9. 7. 2020 v 8:28 odesílatel Amit Khandekar
> napsal:
>
>> On Wed, 17 Jun 2020 at 13:54, Pavel Stehule
>> wrote:
>> >
>> >
>> >
>> > st 17. 6. 2020 v 7:52 odesílatel Amit Khandekar
>> napsal:
>> >>
>> >> On Wed, 10 Jun 2020 at 17:
čt 9. 7. 2020 v 8:28 odesílatel Amit Khandekar
napsal:
> On Wed, 17 Jun 2020 at 13:54, Pavel Stehule
> wrote:
> >
> >
> >
> > st 17. 6. 2020 v 7:52 odesílatel Amit Khandekar
> napsal:
> >>
> >> On Wed, 10 Jun 2020 at 17:12, Pavel Stehule
> wrote:
> >> > st 10. 6. 2020 v 12:26 odesílatel Amit K
On Wed, 17 Jun 2020 at 13:54, Pavel Stehule wrote:
>
>
>
> st 17. 6. 2020 v 7:52 odesílatel Amit Khandekar
> napsal:
>>
>> On Wed, 10 Jun 2020 at 17:12, Pavel Stehule wrote:
>> > st 10. 6. 2020 v 12:26 odesílatel Amit Khandekar
>> > napsal:
>> >> Could you show an example testcase that tests
st 17. 6. 2020 v 7:52 odesílatel Amit Khandekar
napsal:
> On Wed, 10 Jun 2020 at 17:12, Pavel Stehule
> wrote:
> > st 10. 6. 2020 v 12:26 odesílatel Amit Khandekar
> napsal:
> >> Could you show an example testcase that tests this recursive scenario,
> >> with which your earlier patch fails the
On Wed, 10 Jun 2020 at 17:12, Pavel Stehule wrote:
> st 10. 6. 2020 v 12:26 odesílatel Amit Khandekar
> napsal:
>> Could you show an example testcase that tests this recursive scenario,
>> with which your earlier patch fails the test, and this v2 patch passes
>> it ? I am trying to understand th
st 10. 6. 2020 v 12:26 odesílatel Amit Khandekar
napsal:
> On Sat, 16 May 2020 at 00:07, Pavel Stehule
> wrote:
> >
> > Hi
> >
> >>>
> >>> The problem is in plpgsql implementation of CALL statement
> >>>
> >>> In non atomic case - case of using procedures from DO block, the
> expression plan is
On Sat, 16 May 2020 at 00:07, Pavel Stehule wrote:
>
> Hi
>
>>>
>>> The problem is in plpgsql implementation of CALL statement
>>>
>>> In non atomic case - case of using procedures from DO block, the
>>> expression plan is not cached, and plan is generating any time. This is
>>> reason why it i
Em sáb., 16 de mai. de 2020 às 11:07, Pavel Stehule
escreveu:
>
>
> so 16. 5. 2020 v 15:24 odesílatel Ranier Vilela
> napsal:
>
>> Em sáb., 16 de mai. de 2020 às 09:35, Pavel Stehule <
>> pavel.steh...@gmail.com> escreveu:
>>
>>>
>>>
>>> so 16. 5. 2020 v 13:40 odesílatel Ranier Vilela
>>> napsa
so 16. 5. 2020 v 15:24 odesílatel Ranier Vilela
napsal:
> Em sáb., 16 de mai. de 2020 às 09:35, Pavel Stehule <
> pavel.steh...@gmail.com> escreveu:
>
>>
>>
>> so 16. 5. 2020 v 13:40 odesílatel Ranier Vilela
>> napsal:
>>
>>> Em sáb., 16 de mai. de 2020 às 01:10, Pavel Stehule <
>>> pavel.steh..
Em sáb., 16 de mai. de 2020 às 09:35, Pavel Stehule
escreveu:
>
>
> so 16. 5. 2020 v 13:40 odesílatel Ranier Vilela
> napsal:
>
>> Em sáb., 16 de mai. de 2020 às 01:10, Pavel Stehule <
>> pavel.steh...@gmail.com> escreveu:
>>
>>>
>>>
>>> so 16. 5. 2020 v 5:55 odesílatel Ranier Vilela
>>> napsal
so 16. 5. 2020 v 13:40 odesílatel Ranier Vilela
napsal:
> Em sáb., 16 de mai. de 2020 às 01:10, Pavel Stehule <
> pavel.steh...@gmail.com> escreveu:
>
>>
>>
>> so 16. 5. 2020 v 5:55 odesílatel Ranier Vilela
>> napsal:
>>
>>> Em sáb., 16 de mai. de 2020 às 00:07, Pavel Stehule <
>>> pavel.steh...
Em sáb., 16 de mai. de 2020 às 01:10, Pavel Stehule
escreveu:
>
>
> so 16. 5. 2020 v 5:55 odesílatel Ranier Vilela
> napsal:
>
>> Em sáb., 16 de mai. de 2020 às 00:07, Pavel Stehule <
>> pavel.steh...@gmail.com> escreveu:
>>
>>>
>>>
>>> so 16. 5. 2020 v 0:34 odesílatel Ranier Vilela
>>> napsal:
so 16. 5. 2020 v 5:55 odesílatel Ranier Vilela napsal:
> Em sáb., 16 de mai. de 2020 às 00:07, Pavel Stehule <
> pavel.steh...@gmail.com> escreveu:
>
>>
>>
>> so 16. 5. 2020 v 0:34 odesílatel Ranier Vilela
>> napsal:
>>
>>> Em dom., 10 de mai. de 2020 às 17:21, Pavel Stehule <
>>> pavel.steh...@
Em sáb., 16 de mai. de 2020 às 00:07, Pavel Stehule
escreveu:
>
>
> so 16. 5. 2020 v 0:34 odesílatel Ranier Vilela
> napsal:
>
>> Em dom., 10 de mai. de 2020 às 17:21, Pavel Stehule <
>> pavel.steh...@gmail.com> escreveu:
>>
>>> Hi
>>>
>>> I try to use procedures in Orafce package, and I did som
so 16. 5. 2020 v 0:34 odesílatel Ranier Vilela napsal:
> Em dom., 10 de mai. de 2020 às 17:21, Pavel Stehule <
> pavel.steh...@gmail.com> escreveu:
>
>> Hi
>>
>> I try to use procedures in Orafce package, and I did some easy
>> performance tests. I found some hard problems:
>>
>> 1. test case
>>
Em dom., 10 de mai. de 2020 às 17:21, Pavel Stehule
escreveu:
> Hi
>
> I try to use procedures in Orafce package, and I did some easy performance
> tests. I found some hard problems:
>
> 1. test case
>
> create or replace procedure p1(inout r int, inout v int) as $$
> begin v := random() * r; end
Hi
> The problem is in plpgsql implementation of CALL statement
>>
>> In non atomic case - case of using procedures from DO block, the
>> expression plan is not cached, and plan is generating any time. This is
>> reason why it is slow.
>>
>> Unfortunately, generated plans are not released until
po 11. 5. 2020 v 7:25 odesílatel Pavel Stehule
napsal:
> Hi
>
> ne 10. 5. 2020 v 22:20 odesílatel Pavel Stehule
> napsal:
>
>> Hi
>>
>> I try to use procedures in Orafce package, and I did some easy
>> performance tests. I found some hard problems:
>>
>> 1. test case
>>
>> create or replace proc
On Sun, May 10, 2020 at 10:20:53PM +0200, Pavel Stehule wrote:
> When I rewrite same to functions then
>
> create or replace function p1func2(inout r int, inout v int) as $$
> begin v := random() * r; end
> $$ language plpgsql;
>
> Then execution is about 1 sec, and memory requirements are +/- zero
Hi
ne 10. 5. 2020 v 22:20 odesílatel Pavel Stehule
napsal:
> Hi
>
> I try to use procedures in Orafce package, and I did some easy performance
> tests. I found some hard problems:
>
> 1. test case
>
> create or replace procedure p1(inout r int, inout v int) as $$
> begin v := random() * r; end
>
Hi
I try to use procedures in Orafce package, and I did some easy performance
tests. I found some hard problems:
1. test case
create or replace procedure p1(inout r int, inout v int) as $$
begin v := random() * r; end
$$ language plpgsql;
This command requires
do $$
declare r int default 100;
28 matches
Mail list logo