| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Greg Stark <stark(at)enterprisedb(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Teodor Sigaev <teodor(at)sigaev(dot)ru> |
| Subject: | Re: pg_migrator and an 8.3-compatible tsvector data type |
| Date: | 2009-05-29 14:27:27 |
| Message-ID: | 16876.1243607247@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2009-05-29 14:41:53 | Re: Python 3.0 does not work with PL/Python |
| Previous Message | Andrew Dunstan | 2009-05-29 14:11:22 | Re: search_path vs extensions |