From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: pg_dump additional options for performance |
Date: | 2008-07-27 09:37:34 |
Message-ID: | 1217151454.3894.1225.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
On Sat, 2008-07-26 at 11:03 -0700, Joshua D. Drake wrote:
> 2. We have no concurrency which means, anyone with any database over 50G
> has unacceptable restore times.
Agreed.
Also the core reason for wanting -w
> 3. We have to continue develop hacks to define custom utilization. Why
> am I passing pre-data anything? It should be automatic. For example:
>
> pg_backup (not dump, we aren't dumping. Dumping is usually associated
> with some sort of crash or fould human behavoir. We are backing up).
> pg_backup -U <user> -D database -F -f mybackup.sqlc
>
> If I were to extract <mybackup.sqlc> I would get:
>
> mybackup.datatypes
> mybackup.tables
> mybackup.data
> mybackup.primary_keys
> mybackup.indexes
> mybackup.constraints
> mybackup.grants
Sounds good.
Doesn't help with the main element of dump time: one table at a time to
one output file. We need a way to dump multiple tables concurrently,
ending in multiple files/filesystems.
> Oh and pg_dumpall? It should have been removed right around the release
> of 7.2, pg_dump -A please.
Good idea
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2008-07-27 16:57:17 | Re: pg_dump additional options for performance |
Previous Message | Simon Riggs | 2008-07-27 09:31:48 | Re: pg_dump additional options for performance |
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2008-07-27 16:57:17 | Re: pg_dump additional options for performance |
Previous Message | Simon Riggs | 2008-07-27 09:31:48 | Re: pg_dump additional options for performance |