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

Re: patch for parallel pg_dump

From: Joachim Wieland <joe(at)mcknight(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: patch for parallel pg_dump
Date: 2012-02-03 01:31:48
Message-ID: CACw0+10SHPf0jX5mxwUOn+eX0dfmxr6JpyVCS8bC304VuNQHEg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Feb 1, 2012 at 12:24 PM, Robert Haas <robertmhaas(at)gmail(dot)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.

In response to

Responses

pgsql-hackers by date

Next:From: Euler Taveira de OliveiraDate: 2012-02-03 02:31:43
Subject: Re: Patch pg_is_in_backup()
Previous:From: Noah MischDate: 2012-02-02 23:51:28
Subject: Re: show Heap Fetches in EXPLAIN for index-only scans

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