Re: Rethinking plpgsql's assignment implementation

Pavel Stehule <pavel.stehule@gmail.com>

From: Pavel Stehule <pavel.stehule@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Chapman Flack <chap@anastigmatix.net>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-12-14T18:01:17Z
Lists: pgsql-hackers
po 14. 12. 2020 v 17:25 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:

> Pavel Stehule <pavel.stehule@gmail.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
>
>

Commits

  1. Rethink the "read/write parameter" mechanism in pl/pgsql.

  2. Remove PLPGSQL_DTYPE_ARRAYELEM datum type within pl/pgsql.

  3. Re-implement pl/pgsql's expression and assignment parsing.

  4. Add the ability for the core grammar to have more than one parse target.

  5. Support subscripting of arbitrary types, not only arrays.

  6. Improve handling of array elements as getdiag_targets and cursor_variables.