Re: pg_dump additional options for performance

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: daveg <daveg(at)sonic(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: pg_dump additional options for performance
Date: 2008-07-21 21:00:57
Message-ID: 20080721210057.GH18846@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Tom, et al,

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Ah, I see. No objection to those switch names, at least assuming we
> want to stick to positive-logic switches. What did you think of the
> negative-logic suggestion (--omit-xxx)?

My preference is for positive-logic switches in general. The place
where I would use this patch would lend itself to being more options if
--omit-xxxx were used. I expect that would hold true for most people.
It would be:

--omit-data --omit-post-load
--omit-pre-load --omit-post-load
--omit-pre-load --omit-data

vs.

--schema-pre-load
--data-only
--schema-post-load

Point being that I'd be dumping these into seperate files where I could
more easily manipulate the pre-load or post-load files. I'd still want
pre/post load to be seperate though since this would be used in cases
where there's alot of data (hence the reason for the split) and putting
pre and post together and running them before data would slow things
down quite a bit.

Are there use cases for just --omit-post-load or --omit-pre-load?
Probably, but I just don't see any situation where I'd use them like
that.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gurjeet Singh 2008-07-21 21:11:55 Re: Load spikes on 8.1.11
Previous Message Decibel! 2008-07-21 20:58:46 Re: Load spikes on 8.1.11

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2008-07-21 23:19:46 Re: pg_dump additional options for performance
Previous Message Tom Lane 2008-07-21 20:38:57 Re: pg_dump additional options for performance