Re: Rethinking plpgsql's assignment implementation

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Chapman Flack <chap(at)anastigmatix(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Rethinking plpgsql's assignment implementation
Date: 2020-12-14 18:01:17
Message-ID: CAFj8pRDH6PMG-4ozgeapoM4EKP6dKi1ZFyxyB_8=PZ2iZChKMg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

po 14. 12. 2020 v 17:25 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> > I checked a performance and it looks so access to record's field is
> faster,
> > but an access to arrays field is significantly slower
>
> Hmm, I'd drawn the opposite conclusion in my own testing ...
>
> > for i in 1..5000
> > loop
> > if a[i] > a[i+1] then
> > aux := a[i];
> > a[i] := a[i+1]; a[i+1] := aux;
> > rep := true;
> > end if;
> > end loop;
>
> ... but I now see that I'd not checked cases like "a[i] := a[j]".
> exec_check_rw_parameter() is being too conservative about whether
> it can optimize a case like that. The attached incremental patch
> fixes it.
>
> > I tested pi calculation
> > ...
> > And the performance is 10% slower than on master
>
> Can't reproduce that here. For the record, I get the following
> timings (medians of three runs) for your test cases:
>
> HEAD:
>
> sort: Time: 13974.709 ms (00:13.975)
> pi_est_1(10000000): Time: 3537.482 ms (00:03.537)
> pi_est_2(10000000): Time: 3546.557 ms (00:03.547)
>
> Patch v1:
>
> sort: Time: 47053.892 ms (00:47.054)
> pi_est_1(10000000): Time: 3456.078 ms (00:03.456)
> pi_est_2(10000000): Time: 3451.347 ms (00:03.451)
>
> + exec_check_rw_parameter fix:
>
> sort: Time: 12199.724 ms (00:12.200)
> pi_est_1(10000000): Time: 3357.955 ms (00:03.358)
> pi_est_2(10000000): Time: 3367.526 ms (00:03.368)
>
> I'm inclined to think that the differences in the pi calculation
> timings are mostly chance effects; there's certainly no reason
> why exec_check_rw_parameter should affect that test case at all.
>

performance patch helps lot of for sort - with patch it is faster 5-10%
than master 10864 x 12122 ms

I found probably reason why patched was slower

I used

CFLAGS="-fno-omit-frame-pointer -Wall -Wmissing-prototypes
-Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
-Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard
-g -O2 -Werror=switch"

With these options the pi test was slower. When I used default, then there
is no difference.

So it can be very good feature, new code has same speed or it is faster

Regards

Pavel

> regards, tom lane
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2020-12-14 18:12:34 Re: cutting down the TODO list thread
Previous Message Daniil Zakhlystov 2020-12-14 17:53:56 Re: libpq compression