Re: patch for parallel pg_dump

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joachim Wieland <joe(at)mcknight(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: patch for parallel pg_dump
Date: 2012-03-13 13:48:11
Message-ID: 24737.1331646491@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joachim Wieland <joe(at)mcknight(dot)de> writes:
> On Sat, Mar 10, 2012 at 9:51 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> - const char *owner, bool withOids,
>> + const char *owner,
>> + unsigned long int relpages, bool withOids,
>>
>> The new argument to ArchiveEntry() is unused. Removing it would
>> declutter things a good bit.

> How do you mean it's unused? pg_dump_sort.c uses relpages to dump the
> largest tables first. What you don't want to see in a parallel dump is
> a worker starting to dump a large table while everybody else is
> already idle...

Used or not, I think you could find a less ugly and less invasive way to
pass that around than this. We should try to avoid adding arguments to
ArchiveEntry that apply to only one object type.

(I'm also unconvinced that sorting by relation size is a good idea
anyway. Anything that makes the dump order less predictable gets
push-back, IME.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-03-13 13:53:13 Re: Measuring relation free space
Previous Message Robert Haas 2012-03-13 12:43:13 Re: wal_buffers, redux