| From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
|---|---|
| To: | "Joachim Wieland" <joe(at)mcknight(dot)de>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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:59:31 |
| Message-ID: | 4F5F0C7302000025000461EA@gw.wicourts.gov |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> (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.)
Given that people often use diff on files from pg_dump,
unpredictable ordering can be a bad thing. On the other hand, that
is not something you would probably want to do with the output of a
*parallel* dump, so if it only affect that, it probably makes sense.
It seems like a reasonable heuristic to avoid having all but some
big table done, and having to wait for that while the other
processors are sitting idle.
-Kevin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2012-03-13 14:04:34 | Re: patch for parallel pg_dump |
| Previous Message | Hans-Jürgen Schönig | 2012-03-13 13:56:10 | WIP: cross column correlation, 2nd shot |