Re: Manipulating complex types as non-contiguous structures in-memory

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Manipulating complex types as non-contiguous structures in-memory
Дата
Msg-id 26059.1430920209@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  (Pavel Stehule <pavel.stehule@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Parallel Seq Scan
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Patch for bug #12845 (GB18030 encoding)