Re: Dump/Restore performance improvement

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Dump/Restore performance improvement
Дата
Msg-id 29496.1094404063@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Dump/Restore performance improvement  (Adi Alurkar <adi@sf.net>)
Список pgsql-performance
Adi Alurkar <adi@sf.net> writes:
> 1) Add a new config paramter  e.g work_maintanence_max_mem  this will
> the max memory postgresql *can* claim if need be.

> 2) During the dump phase of the DB  postgresql  estimates the
> "work_maintenance_mem" that would be required to create the index in
> memory(if possible) and add's a
> SET work_maintenance_mem="the value calculated"  (IF this value is less
> than work_maintanence_max_mem. )

This seems fairly pointless to me.  How is this different from just
setting maintenance_work_mem as large as you can stand before importing
the dump?

Making any decisions at dump time seems wrong to me in the first place;
pg_dump should not be expected to know what conditions the restore will
be run under.  I'm not sure that's what you're proposing, but I don't
see what the point is in practice.  It's already the case that
maintenance_work_mem is treated as the maximum memory you can use,
rather than what you will use even if you don't need it all.

            regards, tom lane

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

Предыдущее
От: Geoffrey
Дата:
Сообщение: Re: fsync vs open_sync
Следующее
От: Pierre-Frédéric Caillaud
Дата:
Сообщение: Re: fsync vs open_sync