Re: Manipulating complex types as non-contiguous structures in-memory
От | Tom Lane |
---|---|
Тема | Re: Manipulating complex types as non-contiguous structures in-memory |
Дата | |
Msg-id | 24433.1430683063@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Manipulating complex types as non-contiguous structures in-memory (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: Manipulating complex types as non-contiguous structures in-memory
|
Список | pgsql-hackers |
Pavel Stehule <pavel.stehule@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
В списке pgsql-hackers по дате отправления: