Re: [HACKERS] ToDo: fast update of arrays with fixed length fields for PL/pgSQL

2013-11-26 Thread Pavel Stehule
2013/11/25 Tom Lane > Heikki Linnakangas writes: > > In general, I'm not convinced this patch is worth the trouble. The > > speedup isn't all that great; manipulating large arrays in PL/pgSQL is > > still so slow that if you care about performance you'll want to rewrite > > your function in some

Re: [HACKERS] ToDo: fast update of arrays with fixed length fields for PL/pgSQL

2013-11-26 Thread Pavel Stehule
2013/11/25 Heikki Linnakangas > On 07.10.2013 17:00, Pavel Stehule wrote: > >> Hello >> >> I fixed patch - there was a missing cast to domain when it was used (and >> all regress tests are ok now). >> > > This doesn't work correctly for varlen datatypes. I modified your > quicksort example to wor

Re: [HACKERS] ToDo: fast update of arrays with fixed length fields for PL/pgSQL

2013-11-25 Thread Tom Lane
Heikki Linnakangas writes: > In general, I'm not convinced this patch is worth the trouble. The > speedup isn't all that great; manipulating large arrays in PL/pgSQL is > still so slow that if you care about performance you'll want to rewrite > your function in some other language or use tempor

Re: [HACKERS] ToDo: fast update of arrays with fixed length fields for PL/pgSQL

2013-11-25 Thread Heikki Linnakangas
(sorry for possible duplicates, used wrong account on first try) On 07.10.2013 17:00, Pavel Stehule wrote: Hello I fixed patch - there was a missing cast to domain when it was used (and all regress tests are ok now). This doesn't work correctly for varlen datatypes. I modified your quicksort

Re: [HACKERS] ToDo: fast update of arrays with fixed length fields for PL/pgSQL

2013-11-21 Thread Rushabh Lathia
Hi, I started reviewing this patch. Gone through the mail thread discussion to understand the need of the patch. With patch there is significant performance improvement in case of update for the array scalar variable. - Patch gets apply cleanly on master branch - make, make install and make check

Re: [HACKERS] ToDo: fast update of arrays with fixed length fields for PL/pgSQL

2013-10-07 Thread Pavel Stehule
2013/10/7 Andres Freund > On 2013-10-07 16:00:54 +0200, Pavel Stehule wrote: > > /* > >* We need to do subscript evaluation, > which might require > > @@ -4321,6 +4322,14 @@ exec_assign_value(PLpgSQL_execstate *estate, > >

Re: [HACKERS] ToDo: fast update of arrays with fixed length fields for PL/pgSQL

2013-10-07 Thread Andres Freund
On 2013-10-07 16:00:54 +0200, Pavel Stehule wrote: > /* >* We need to do subscript evaluation, which > might require > @@ -4321,6 +4322,14 @@ exec_assign_value(PLpgSQL_execstate *estate, > oldarrayv

Re: [HACKERS] ToDo: fast update of arrays with fixed length fields for PL/pgSQL

2013-10-07 Thread Pavel Stehule
Hello I fixed patch - there was a missing cast to domain when it was used (and all regress tests are ok now). a some performance tests set array_fast_update to off; postgres=# select fill_2d_array(300,300); fill_2d_array ─── 9 (1 row) Time: 33570.087 ms postgres=# set

Re: [HACKERS] ToDo: fast update of arrays with fixed length fields for PL/pgSQL

2013-10-04 Thread Pavel Stehule
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 ─── 9 (1 row) Time: 751.572 ms -- patched postgres=# \q bash-4.1$ psql postg

Re: [HACKERS] ToDo: fast update of arrays with fixed length fields for PL/pgSQL

2013-10-03 Thread Pavel Stehule
Hello a very ugly test shows a possibility about 100% speedup on reported example (on small arrays, a patch is buggy and doesn't work for larger arrays). I updated a code to be read only CREATE OR REPLACE FUNCTION public.fill_2d_array(rows integer, cols integer) RETURNS integer LANGUAGE plpgs

Re: [HACKERS] ToDo: fast update of arrays with fixed length fields for PL/pgSQL

2013-10-03 Thread Pavel Stehule
2013/10/3 Tom Lane > Pavel Stehule 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 > v

Re: [HACKERS] ToDo: fast update of arrays with fixed length fields for PL/pgSQL

2013-10-03 Thread Tom Lane
Pavel Stehule 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

Re: [HACKERS] ToDo: fast update of arrays with fixed length fields for PL/pgSQL

2013-10-02 Thread Pavel Stehule
2013/10/2 Andres Freund > Hi, > > On 2013-10-02 18:56:51 +0200, Pavel Stehule wrote: > > Hello > > > > this proposal is related to reported issue > > > http://www.postgresql.org/message-id/e1vquta-0007y4...@wrigleys.postgresql.org > > > > > > We can directly modify any fields of int, float, doubl

Re: [HACKERS] ToDo: fast update of arrays with fixed length fields for PL/pgSQL

2013-10-02 Thread Andres Freund
Hi, On 2013-10-02 18:56:51 +0200, Pavel Stehule wrote: > Hello > > this proposal is related to reported issue > http://www.postgresql.org/message-id/e1vquta-0007y4...@wrigleys.postgresql.org > > > We can directly modify any fields of int, float, double arrays (when result > size will be immutab

[HACKERS] ToDo: fast update of arrays with fixed length fields for PL/pgSQL

2013-10-02 Thread Pavel Stehule
Hello this proposal is related to reported issue http://www.postgresql.org/message-id/e1vquta-0007y4...@wrigleys.postgresql.org We can directly modify any fields of int, float, double arrays (when result size will be immutable). This trick is used now for acceleration of some aggregates. Ideas,