Re: logical column position
От | Bruce Momjian |
---|---|
Тема | Re: logical column position |
Дата | |
Msg-id | 200311180139.hAI1dFD19793@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: logical column position (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: logical column position
|
Список | pgsql-hackers |
Neil Conway wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > I don't think you can speak of "bloat" for pg_attribute. But you > > can speak of a problem when you want to do the old col = col + 1 in > > the presence of a unique index. > > I'm sorry, but I'm not sure what either of these comments mean -- can > you elaborate? Peter is pointing out a problem with our unique indexes that might cause you a problem. Suppose you have a unique index in attlognum:test=> create table xx( lognum int);CREATE TABLEtest=>insert into xx values (1);INSERT 17145 1test=> insert into xx values (2);INSERT 17146 1test=> update xx set lognum= lognum + 1;UPDATE 2test=> create unique index yy on xx (lognum);CREATE INDEXtest=> update xx set lognum = lognum+ 1;ERROR: duplicate key violates unique constraint "yy" There is discussion to delay unique constraint failures until commit, then recheck them to see if they are still valid, sort of like what we do with deferred triggers. This would fix the problem because on commit, those values are unique, but aren't while the rows are updated invidually. If we don't get that working you might want to use the 1000 gap idea because it doesn't cause this problem, and we don't support >1600 columns, so a 1000 gap shouldn't cause a problem and can be modified later. If they hit 999 updates, just tell them to dump/reload the table. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: