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

From Joachim Wieland
Subject Re: patch for parallel pg_dump
Date
Msg-id CACw0+10SHPf0jX5mxwUOn+eX0dfmxr6JpyVCS8bC304VuNQHEg@mail.gmail.com
Whole thread Raw
In response to Re: patch for parallel pg_dump  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: patch for parallel pg_dump  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, Feb 1, 2012 at 12:24 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> I think we're more-or-less proposing to rename "Archive" to
> "Connection", aren't we?
>
> And then ArchiveHandle can store all the things that aren't related to
> a specific connection.

How about something like that:
(Hopefully you'll come up with better names...)

StateHandle {  Connection  Schema  Archive  Methods  union {     DumpOptions     RestoreOptions  }
}

Dumping would mean to do:
 Connection -> Schema -> Archive using DumpOptions through the
specified Methods

Restore:
  Archive -> Schema -> Connection using RestoreOptions through the
specified Methods

Dumping from one database and restoring into another one would be two
StateHandles with different Connections, Archive == NULL, Schema
pointing to the same Schema, Methods most likely also pointing to the
same function pointer table and each with different Options in the
union of course.

Granted, you could say that above I've only grouped the elements of
the ArchiveHandle, but I don't really see that breaking it up into
several objects makes it any better or easier. There could be some
accessor functions to hide the details of the whole object to the
different consumers.


pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: show Heap Fetches in EXPLAIN for index-only scans
Next
From: Euler Taveira de Oliveira
Date:
Subject: Re: Patch pg_is_in_backup()