Re: Fast AT ADD COLUMN with DEFAULTs

Поиск
Список
Период
Сортировка
От Serge Rielau
Тема Re: Fast AT ADD COLUMN with DEFAULTs
Дата
Msg-id B6A11E38-3A41-4219-AC02-5F4CC30BCC84@rielau.com
обсуждение исходный текст
Ответ на Re: Fast AT ADD COLUMN with DEFAULTs  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Fast AT ADD COLUMN with DEFAULTs  (Vitaly Burovoy <vitaly.burovoy@gmail.com>)
Список pgsql-hackers
> On Oct 6, 2016, at 9:01 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> BTW, it also occurs to me that there are going to be good implementation
> reasons for restricting it to be a hard constant, not any sort of
> expression.  We are likely to need to be able to insert the value in
> low-level code where general expression evaluation is impractical.
>
Yes, the padding must happen primarily in the getAttr() routines.
Clearly we do not want to evaluate an expression there.
But what speaks against evaluating the expression before we store it?
After all we seem to all agree that this only works if the expression computes to the same constant all the time.

If we do not want to store an “untyped” datum straight in pg_attribute as a BYTEA (my current approach) we could store
thepretty printed version of the constant 
and evaluate that when we build the tuple descriptor.
This happens when we load the relation into the relcache.

Anyway, I’m jumping ahead and it’s perhaps best to let the code speak for itself once I have the WIP patch ready so we
havesomething concrete to discuss 

Cheers
Serge





В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: memory leak in e94568ecc10 (pre-reading in external sort)
Следующее
От: Vitaly Burovoy
Дата:
Сообщение: Re: Fast AT ADD COLUMN with DEFAULTs