From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Manipulating complex types as non-contiguous structures in-memory |
Date: | 2015-05-03 19:57:43 |
Message-ID: | 24433.1430683063@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2015-05-03 20:07:13 | Re: Failure to coerce unknown type to specific type |
Previous Message | Tom Lane | 2015-05-03 19:33:51 | Re: Failure to coerce unknown type to specific type |