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 26059.1430920209@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  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
Pavel Stehule <pavel.stehule@gmail.com> writes:
> Multidimensional append is slower 2x .. but it is probably corner case

> declare a int[] := '{}'; begin for i in 1..90000 loop a := a || ARRAY[[i
> ]]; end loop; raise notice '%', 'aa'; end$$ language plpgsql;

Yeah, that's array_cat(), which I've not done anything with.  I'm not
really excited about adding code to it; I think use-cases like this one
are probably too uncommon to justify more code.  In any case we could
go back and improve it later if there are enough complaints.

Another way to look at it is that in this example, plpgsql's attempts to
force the "a" array into expanded form are a mistake: we never get any
benefit because array_cat() just wants it in flat form again, and delivers
it in flat form.  (It's likely that this is an unrealistic worst case:
it's hard to imagine real array-using applications that never do any
element-by-element access.)  Possibly we could improve matters with a more
refined heuristic about whether to force arrays to expanded form during
assignments --- but I'm not sure what that would look like.  plpgsql has
very little direct knowledge of which operations will be applied to the
array later.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Parallel Seq Scan
Next
From: Robert Haas
Date:
Subject: Re: Patch for bug #12845 (GB18030 encoding)