Re: Manipulating complex types as non-contiguous structures in-memory - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Manipulating complex types as non-contiguous structures in-memory
Date
Msg-id 24433.1430683063@sss.pgh.pa.us
Whole thread Raw
In response to Re: Manipulating complex types as non-contiguous structures in-memory  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: Manipulating complex types as non-contiguous structures in-memory  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Manipulating complex types as non-contiguous structures in-memory
Next
From: Magnus Hagander
Date:
Subject: Re: initdb start server recommendation