From: | Adi Alurkar <adi(at)sf(dot)net> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Dump/Restore performance improvement |
Date: | 2004-09-05 04:07:26 |
Message-ID: | 18A61C72-FEF1-11D8-8BA3-000A95C4BD7A@sf.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)vasoftware(dot)com>
1024D/79730470 A491 5724 74DE 956D 06CB D844 6DF1 B972 7973 0470
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Bergman | 2004-09-05 05:16:42 | Re: fsync vs open_sync |
Previous Message | Christopher Browne | 2004-09-05 03:47:55 | Re: fsync vs open_sync |