Re: Alter domain type / avoiding table rewrite

Поиск
Список
Период
Сортировка
От Adrian Klaver
Тема Re: Alter domain type / avoiding table rewrite
Дата
Msg-id 2f57aafd-f034-0f82-5739-614607e4ba0e@aklaver.com
обсуждение исходный текст
Ответ на Re: Alter domain type / avoiding table rewrite  (Tim Kane <tim.kane@gmail.com>)
Ответы Re: Alter domain type / avoiding table rewrite  (Tim Kane <tim.kane@gmail.com>)
Список pgsql-general
On 4/16/19 9:18 AM, Tim Kane wrote:
> Thanks everyone..
> 
> It seems that the first step:
> 
> old_type --> varchar(9)
> 
> still requires a table rewrite, while the reverse direction does not.

Hmm:

CREATE DOMAIN old_type AS varchar(9);

create table rewrite_test (id integer, fld_1 old_type);

insert into rewrite_test values (1, '123456789'), (2, '123');

select ctid from rewrite_test;
  ctid
-------
  (0,1)
  (0,2)

alter table rewrite_test alter COLUMN fld_1 set data type varchar(9);

select ctid from rewrite_test;
  ctid
-------
  (0,1)
  (0,2)

update rewrite_test set fld_1 = '1' where id =2;

select ctid from rewrite_test; 
 

  ctid 
 
 

------- 
 
 

  (0,1) 
 
 

  (0,3)

Where are you seeing the rewrite in your case?

> 
> 
> I'm curious about the performance implication of domain types, i expect 
> that cost is only at insert/update time? I guess we've been wearing that 
> cost up until now.
> 
> Adrian is correct - the intention for the DOMAIN with CHECK approach was 
> to allow flexibility moving forward, as the data set is particularly 
> large...
> 
> I'm now thinking that since promotion to a larger size is a non-issue, 
> and domain type seems to be not quite the panacea I hoped, then the use 
> of varchar(n) is perhaps not so terrible!
> 
> Thanks for the advice/suggestions/discussion :)
> 
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com



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

Предыдущее
От: Zahir Lalani
Дата:
Сообщение: Possible corrupt index?
Следующее
От: Michael Lewis
Дата:
Сообщение: Re: Possible corrupt index?