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
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
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
(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
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
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,
> >
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
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
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
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
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
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
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
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
14 matches
Mail list logo
