Re: patch for parallel pg_dump - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: patch for parallel pg_dump
Date
Msg-id 4F61021F.6010201@postgresql.org
Whole thread Raw
In response to Re: patch for parallel pg_dump  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: patch for parallel pg_dump
Re: patch for parallel pg_dump
Re: patch for parallel pg_dump
List pgsql-hackers
On 03/13/2012 02:10 PM, Andrew Dunstan wrote:
>
>
> On 03/13/2012 01:53 PM, Robert Haas wrote:
>>>
>>> I tried this actually (patch attached) but then I wanted to test it
>>> and couldn't find anything that used pgpipe() on Windows.
>>>
>>> pg_basebackup/pg_basebackup.c is using it but it's in an #ifndef WIN32
>>> and the same is true for postmaster/syslogger.c. Am I missing
>>> something or has this Windows implementation become stale by now? I'll
>>> append the patch but haven't adapted the pg_dump patch yet to use it.
>>> Should we still go forward the way you proposed?
>> Dunno.  Can we get an opinion on that from one of the Windows guys?
>> Andrew, Magnus?
>>
>>
>
> I haven't had time to review this patch or even follow all the 
> discussion as I was hoping. I'll try to review the whole thing shortly.


pgpipe used to be used in pgstat.c, but that's no longer true in any 
live branch, so it's probably long dead. I'd be inclined to rip it out 
if possible rather than expand its use.

I've just started looking at the patch, and I'm curious to know why it 
didn't follow the pattern of parallel pg_restore which created a new 
worker for each table rather than passing messages to looping worker 
threads as this appears to do. That might have avoided a lot of the need 
for this message passing infrastructure, if it could have been done. But 
maybe I just need to review the patch and the discussions some more.

cheers

andrew







pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: CREATE FOREGIN TABLE LACUNA
Next
From: Peter Eisentraut
Date:
Subject: Re: pg_upgrade and statistics