Re: restore time: sort_mem vs. checkpoing_segments
| От | Tom Lane |
|---|---|
| Тема | Re: restore time: sort_mem vs. checkpoing_segments |
| Дата | |
| Msg-id | 14070.1063689540@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | restore time: sort_mem vs. checkpoing_segments (Vivek Khera <khera@kcilink.com>) |
| Ответы |
Re: restore time: sort_mem vs. checkpoing_segments
|
| Список | pgsql-performance |
Vivek Khera <khera@kcilink.com> writes:
> Restore of a significanly big database (~19.8GB restored) shows nearly
> no time difference depending on sort_mem when checkpoint_segments is
> large. There are quite a number of tables and indexes. The restore
> was done from a pg_dump -Fc dump of one database.
I was just bugging Marc for some useful data, so I'll ask you too:
could you provide a trace of the pg_restore execution? log_statement
plus log_duration output would do it. I am curious to understand
exactly which steps in the restore are significant time sinks.
> I notice during the restore that the disk throughput triples during
> the checkpoint.
Hm, better make sure the log includes some indication of when
checkpoints happen.
regards, tom lane
В списке pgsql-performance по дате отправления: