Re: ToDo: fast update of arrays with fixed length fields for PL/pgSQL - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: ToDo: fast update of arrays with fixed length fields for PL/pgSQL
Date
Msg-id CAFj8pRAeyqhvKNaeaz8V+schvno4grbv-7_o49Q8urNXO4LbFg@mail.gmail.com
Whole thread Raw
In response to Re: ToDo: fast update of arrays with fixed length fields for PL/pgSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hello

I am sending little bit cleaned patch

there is significant speedup (on example from bug report) - more than 100x on my Dell D830

postgres=# select fill_2d_array(300,300,1);
 fill_2d_array
───────────────
         90000
(1 row)

Time: 751.572 ms -- patched
postgres=# \q
bash-4.1$ psql postgres
psql (9.4devel)
Type "help" for help.

postgres=# select fill_2d_array(300,300,2);
 fill_2d_array
───────────────
         90000
(1 row)

Time: 87453.351 ms -- original

I checked a result and it is same.

Probably there are some issues, because domain tests fails, but these numbers shows so a significantly faster array update is possible.

Interesting - I did a profiling and I didn't find anything interesting :(

Regards

Pavel







2013/10/3 Tom Lane <tgl@sss.pgh.pa.us>
Pavel Stehule <pavel.stehule@gmail.com> writes:
> If you can do a update of some array in plpgsql now, then you have to work
> with local copy only. It is a necessary precondition, and I am think it is
> valid.

If the proposal only relates to assignments to elements of plpgsql local
variables, it's probably safe, but it's also probably not of much value.
plpgsql has enough overhead that I'm doubting you'd get much real-world
speedup.  I'm also not very excited about putting even more low-level
knowledge about array representation into plpgsql.

                        regards, tom lane

Attachment

pgsql-hackers by date:

Previous
From: Oskari Saarenmaa
Date:
Subject: Re: [PATCH] pg_upgrade: support for btrfs copy-on-write clones
Next
From: David Rowley
Date:
Subject: Re: pg_dump insert with column names speedup