Andrew Dunstan <and...@dunslane.net> wrote: > I did this, but it turned out that the problem was a logic error that I > found once I had managed to get a working debugger. However, the Windows > thread code should now be more robust, so thanks to Andrew and Magnus > for the suggestions.
Hello, I tested parallel restore on Windows. I have some random comments about it: * Two compiler warnings. pg_backup_custom.c: In function `_PrintTocData': pg_backup_custom.c:437: warning: unused variable `ctx' pg_backup_custom.c: In function `_ReopenArchive': pg_backup_custom.c:849: warning: unused variable `ctx' * No description about new options in pg_restore --help. There are no help messages about multi-thread (-m) and truncate-before-load options. * multi-thread option is ignored if --data-only is on. Is it an intended behavior? Even if so, we'd better to have warning messages here. * Threads, forked processes and connections are disposed per entry. I think it's a designed behavior, but there might be room for improvement. The present implementation is slower when there are many small objects. If we can specialize in thread-based implementation, thread pooling and connections pooling are typically used in the context. -- it might be a ToDo item in 8.5. ---- I have no idea about performance because I don't have multi-core machine for windows. Parallel restore seems to be slower than serial restore on single-cpu machine. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
