2015-05-06 15:50 GMT+02:00 Tom Lane <t...@sss.pgh.pa.us>:
> Pavel Stehule <pavel.steh...@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.
>
Isn't better to push information about possible target to function?
array_cat(a, b, result)
{
if (undef(result))
return a || b;
if (b == result)
array_extend(result, a);
return result;
else if (a == result)
array_extend(result, b);
return result;
else
return a || b;
}
It can be used for arrays, for strings?
On second hand it decrease readability related functions :( (but not all
functions should to support this optimization).
Regards
Pavel
> regards, tom lane
>
