Re: Allowing parallel pg_restore from pipe

Поиск
Список
Период
Сортировка
От Timothy Garnett
Тема Re: Allowing parallel pg_restore from pipe
Дата
Msg-id CAPcyiQ0xU4Mhf3h9m9yf2fov6dToU2q71krewiqC3T_NV0NUrA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Allowing parallel pg_restore from pipe  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On Tue, Dec 3, 2013 at 12:14 PM, Bruce Momjian <bruce@momjian.us> wrote:
On Wed, Apr 24, 2013 at 03:33:42PM -0400, Andrew Dunstan wrote:
>
> On 04/23/2013 07:53 PM, Timothy Garnett wrote:
...
> >Attached is two diffs off of the REL9_2_4 tag that I've been
> >using.  The first is a simple change that serially loads the data
> >section before handing off the remainder of the restore to the
> >existing parallelized restore code (the .ALT. diff).  The second
> >which gets more parallelization but is a bit more of a change uses
> >the existing dependency analysis code to allow index building etc.
> >to occur in parallel with data loading. The data loading tasks are
> >still performed serially in the main thread, but non-data loading
> >tasks are scheduled in parallel as their dependencies are
> >satisfied (with the caveat that the main thread can only dispatch
> >new tasks between data loads).
...
>
>
> I don't think these are bad ideas at all, and probably worth doing.
> Note that there are some fairly hefty changes affecting this code in
> master, so your rebasing could be tricky.

Is there any progress on this:  doing parallel pg_restore from a pipe?


We're on 9.2 and making make extensive use of the patch in the original post.  I will probably forward port it to 9.3 when we migrate to that (probably sometime Q1) since we pretty much require it in our setup.

Tim

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Why we are going to have to go DirectIO
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Why we are going to have to go DirectIO