Skip site navigation (1) Skip section navigation (2)

Re: pg_dump additional options for performance

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Jeff Davis" <pgsql(at)j-davis(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump additional options for performance
Date: 2008-02-27 02:03:45
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> I think a sane way to think about what Simon would like to accomplish
> is not "turn psql into a parallel job scheduler" but "teach pg_restore
> how to do parallel scheduling, and then see if it can be made to do
> anything useful with plain-text instead of archive-dump input".
> At least that way you're talking about something that's within the scope
> of the program's purpose.

Er, yes, that's what I meant. My point though was just that for single
commands which take a long time to run on the server there's no additional
work in the client needed to handle it. That is, as opposed to handling
multiple COPYs in parallel where psql has to be involved in the actual data
transfer and so you need multiple client as well as server processes.

I think I'm sorry I got involved here though since I specifically do not have
either the full context of this discussion or any background in
pg_dump/pg_restore code.

  Gregory Stark
  Ask me about EnterpriseDB's PostGIS support!

In response to

pgsql-hackers by date

Next:From: Brendan JurdDate: 2008-02-27 02:05:44
Subject: Re: One more option for pg_dump...
Previous:From: Peter EisentrautDate: 2008-02-27 00:50:08
Subject: Re: Required make version

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group