Re: check point segments leakage ?

Поиск
Список
Период
Сортировка
От Gaetano Mendola
Тема Re: check point segments leakage ?
Дата
Msg-id 40FE339C.30308@bigfoot.com
обсуждение исходный текст
Ответ на Re: check point segments leakage ?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: check point segments leakage ?
Список pgsql-hackers
Bruce Momjian wrote:
> Gaetano Mendola wrote:>>>Bruce Momjian wrote:>>>>>>>Scott Marlowe wrote:>>>>>>>>>>>>I use a checkpoint_segments = 16
butin my pg_xlog I have>>>>>>35 files. Why 35 files ?>>>>>>>>>You have 35 because the max files in pg_xlog is
2*checkpoint_segments+1>>>or something like that. This is documented in the SGML.>>>>Ok, that explain why. And they
willremain there also if not needed ?>>> Yes, it keeps them around so it doesn't need to recreate them.>>>>Another
weirdbehaviour is that during the day the storage space usage>>increase gruadualy. Since today as the graph show the
spaceusage>>is constant, it's like if some space was pre-allocated and now is>>used, see same yesterday period between
18:00and 24:00.>>Toughts ?>>> My guess is that you need a certain amount of free space in the tables> to operate
properly.

Well, today I stop the pg_autovacuum and I did a vacuum full and I reindexed
all big tables and other 500 MB were reclamed. Could be the pg_autovacuum
running yesterday the responsible for these 500MB not reclamed during
a vacuum full and reindex already performed yesterday ?

I'm wandering if will be possible in the 7.5 start and stop the the
autovacuum integrated in the backend.

I don't know if there is space for improvements but add columns to a table
with milion rows is very painfull, for sure could be usefull to do the
following tree operation in one shot:

1) Add column
2) Update the column
3) Set not null




Regards
Gaetano Mendola




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

Предыдущее
От: Gaetano Mendola
Дата:
Сообщение: unused variable
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: unused variable