Dump/Restore performance improvement

Поиск
Список
Период
Сортировка
От Adi Alurkar
Тема Dump/Restore performance improvement
Дата
Msg-id 18A61C72-FEF1-11D8-8BA3-000A95C4BD7A@sf.net
обсуждение исходный текст
Ответы Re: Dump/Restore performance improvement  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
Greetings,

I have observed that in a dump/restore scenario the longest time is
spent on index creation for larger tables, I have a suggestion of how
the performance could be improved thus reducing the time to recover
from a crash. Not sure if this is possible but would definitely be a
nice addition to the TODO list.

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. )

3) During the restore phase the appropriate memory is allocated in RAM
and the index creation takes less time since PG does not have to sort
on disk.

--
Adi Alurkar (DBA sf.NET) <adi@vasoftware.com>
1024D/79730470 A491 5724 74DE 956D 06CB  D844 6DF1 B972 7973 0470


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

Предыдущее
От: Christopher Browne
Дата:
Сообщение: Re: fsync vs open_sync
Следующее
От: Steve Bergman
Дата:
Сообщение: Re: fsync vs open_sync