Re: [ADMIN] Strange behaviour
От | Lorenzo Huerta |
---|---|
Тема | Re: [ADMIN] Strange behaviour |
Дата | |
Msg-id | 19980911145706.27749.rocketmail@send101.yahoomail.com обсуждение исходный текст |
Список | pgsql-admin |
I have 11K records in my table with two fields being uniquely indexed, would this matter. Everytime i do an update, which is 2 times a week, i do all my adds,deletes,mods on the database then for all the text fields that are blank i make them NUll as it feel it might increase speed of a lookup, after i do that i always do a 'vacuum analyze' on the databases i use. To make sure all the system catalogs are kept up to date. -lorenzo ---Alexei Vladishev <alex@gobbo.caves.lv> wrote: > > Greetings, > > Normal vacuum don't do the trick. I made simple script which once in a > hour vacuums my most used table. Today, in the morning, i found that the > script crashed with message "Cannot write duplicate key ...". So it is not > right solution for the problem. > Dropping and recreating indexes is a good idea if your table is not > large. For small tables I reccomend "dump table"->"drop table"->"create > table+loading data+creating indexes" schema. Why drop table ? Because > dropping table inproves performance, it simply becomes smaller. > > Yours sincerely, > Alexei Vladishev > > On Thu, 10 Sep 1998, Lorenzo Huerta wrote: > > > Alexi and group, > > > > Another good question to ask wrt alexi's question is it > > good practice to everyonce in a while to reconstruct an > > index from scratch. Or would a normal vacuum do the trick? > > > > -lorenzo > > > > > > ---Alexei Vladishev <alex@gobbo.caves.lv> wrote: > > > > > > Greetings, > > > > > > I have an aplication which do pretty much updates/selects on table > > TABLE. > > > (about 3-6 updates/selects in a sec.). The TABLE has an unique > > index, lets > > > call it INDEX. It seems than everything works OK. But after 4-7 > > hours I > > > get the following errors from the application - PGresult is null, > > Backend > > > died... After a couple of days of investigation I understood that the > > > problem is in indexe, because it dies on SELECT * FROM TABLE WHERE > > > zzz=33; and zzz is the unique key of the table. After dropping index > > and > > > recreating one problem disappers. > > > > > > Is there a patch to heal postgres ? Can anyone help me ? > > > Thanks > > > > > > I am running Postgresql 6.3.2+Btree patch on Intel Linux 2.0.32 > > (RedHat > > > 5.0). > > > > > > Yours sincerely, > > > Alexei Vladishev > > > > > > > > > > > > > _________________________________________________________ > > DO YOU YAHOO!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com
В списке pgsql-admin по дате отправления: