Re: Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
От | Tom Lane |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog, |
Дата | |
Msg-id | 14149.1234384833@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog, (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: Re: [COMMITTERS] pgsql: Update autovacuum to use
reloptions instead of a system catalog,
Re: Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog, |
Список | pgsql-hackers |
Alvaro Herrera <alvherre@commandprompt.com> writes: > However, Takahiro-san and Euler's position is that if you do this: > create table foo (f1 int) with (toast.fillfactor = 70); > alter table foo add column f2 text; > Then the toast table should have the fillfactor setting. Well, that might look sensible when phrased that way. But the more likely scenario would be that you add column f2 six months later, at which point there is room for pretty serious doubt that the option you specified way back when would still be the optimal choice. I'm just fine with the concept that if ADD COLUMN causes a toast table to get created, that table will have default reloptions. If you want nondefault toast reloptions, having to specify what you want after the table exists (and you know what's in it) seems reasonable to me. Or to put it another way: it seems to me that the use-case being argued here is really for being able to adjust the default toast reloptions. Not to have action at a distance on a table that doesn't exist and you have no way to know when you set the option what will be in it when it does exist. regards, tom lane
В списке pgsql-hackers по дате отправления: