Re: ToDo: fast update of arrays with fixed length fields for PL/pgSQL
От | Pavel Stehule |
---|---|
Тема | Re: ToDo: fast update of arrays with fixed length fields for PL/pgSQL |
Дата | |
Msg-id | CAFj8pRB+RzMmy4K2_DeHecz5k6MigmD=uQmayQ4SWQNZesj2TA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ToDo: fast update of arrays with fixed length fields for PL/pgSQL (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: ToDo: fast update of arrays with fixed length fields
for PL/pgSQL
|
Список | pgsql-hackers |
2013/10/7 Andres Freund <andres@2ndquadrant.com>
On 2013-10-07 16:00:54 +0200, Pavel Stehule wrote:
> /*
> * We need to do subscript evaluation, which might require
> @@ -4321,6 +4322,14 @@ exec_assign_value(PLpgSQL_execstate *estate,
> oldarrayval = (ArrayType *) DatumGetPointer(oldarraydatum);
>
> /*
> + * support fast update for array scalar variable is enabled only
> + * when target is a scalar variable and variable holds a local
> + * copy of some array.
> + */
> + inplace_update = (((PLpgSQL_datum *) target)->dtype == PLPGSQL_DTYPE_VAR
> + && ((PLpgSQL_var *) target)->freeval);
> +
> + /*
> * Build the modified array value.
> */
Will this recognize if the local Datum is just a reference to an
external toast Datum (i.e. varattrib_1b_e)?
this works on plpgsql local copies only (when cleaning is controlled by plpgsql) - so it should be untoasted every time.
btw when I tested this patch I found a second plpgsql array issue - repeated untoasting :( and we should not forget it.
I don't know much about plpgsql's implementation, so please excuse if
the question is stupid.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: