Re: [ADMIN] slower every day
От | G u i d o B a r o s i o |
---|---|
Тема | Re: [ADMIN] slower every day |
Дата | |
Msg-id | 20040901115853.309FB6C4F2@honorio.sinectis.com.ar обсуждение исходный текст |
Ответы |
Re: [PERFORM] [ADMIN] slower every day
|
Список | pgsql-hackers |
Again me, To make it easier. Situation A: log_something = true Situation B: # log_something = <anything> Situation C: log_something = false After the pg_ctl reload: Situation B = Situation A Situation C <> (Situation A || Situation B) Is this the expected behavior? Conclusion: If you comment a line on the conf file, and reload it, will remain in the last state. (either wast true or false, while Iexpected a default) Regards > The solution appeared as something I didn't know > > On the .conf file > > Previous situation: > > #log_something=false > log_something=true > > Worst situation > #log_something=false > #log_something=true > > Nice situation > log_something=false > #log_something=true > > > Ok, the problem was that I assumed that commenting a value on > the conf file will set it up to a default (false?). I was wrong. > My server was writting tons of log's. > > Is this the normal behavior for pg_ctl reload? It seems that looks for new values, remembering the last state on the onesthat actually are commented. Although it's my fault to have 2 (tow) lines for the same issue, and that I should realizethat this is MY MISTAKE, the log defaults on a reload, if commented, tend to be the last value entered? > > Regards, > Guido > > > > Am Mittwoch, 1. September 2004 12:06 schrieb G u i d o B a r o s i o: > > > The problem is the time that the postgres takes to perform/return a > > > query. For example, trying the \d <tablename> command takes between 4 or 5 > > > seconds. This table is very big, but I am not asking for the rows, only > > > asking the table schema, so...why is this so slow?!?!? My last > > > administrative action into this table was a reindex to all the indexes via > > > the BKI in standalone mode. I thought I suceed, but this was las saturday. > > > > Do you regularly vacuum and analyze the database? > > > > -- > > Peter Eisentraut > > http://developer.postgresql.org/~petere/ > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 8: explain analyze is your friend > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster
В списке pgsql-hackers по дате отправления: