Re: pg_migrator and an 8.3-compatible tsvector data type
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: pg_migrator and an 8.3-compatible tsvector data type |
| Дата | |
| Msg-id | 16876.1243607247@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: pg_migrator and an 8.3-compatible tsvector data type (Alvaro Herrera <alvherre@commandprompt.com>) |
| Список | pgsql-hackers |
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Bruce Momjian wrote:
>> Alvaro Herrera wrote:
>>> Why not? Right now it's single-threaded. Would it be faster if it ran
>>> several copies in parallel?
>>
>> Sure, but that assumes you have parallel I/O channels; I assume right
>> now it is I/O limited.
> But so does parallel pg_restore, no?
The point of parallel pg_restore is that COPY is frequently CPU-bound to
some extent, and so you can put multiple CPUs to work by parallelizing.
I find it much less probable that multiple "cp" operations can be
parallelized, unless the DB is spread across multiple tablespaces and
the code is smart enough to interleave by tablespace.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера