Pavel Stehule <pavel.steh...@gmail.com> writes:
> Some slowdown is visible (about 10%) for query
> update foo set a = a || 1;
> Significant slowdown is on following test:
> do $$ declare a int[] := '{}'; begin for i in 1..90000 loop a := a || 10;
> end loop; end$$ language plpgsql;
> do $$ declare a numeric[] := '{}'; begin for i in 1..90000 loop a := a ||
> 10.1; end loop; end$$ language plpgsql;
> integer master 14sec x patched 55sec
> numeric master 43sec x patched 108sec
> It is probably worst case - and it is known plpgsql antipattern
Yeah, I have not expended a great deal of effort on the array_append/
array_prepend/array_cat code paths. Still, in these plpgsql cases,
we should in principle have gotten down from two array copies per loop to
one, so it's disappointing to not have better results there, even granting
that the new "copy" step is not just a byte-by-byte copy. Let me see if
there's anything simple to be done about that.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
