yed product.
Thanks again for your input,
--patrick
On 4/18/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> "patrick keshishian" <[EMAIL PROTECTED]> writes:
> > I've been struggling with some performance issues with certain
> > SQL queries. I was prepping a l
Hi all,
I've been struggling with some performance issues with certain
SQL queries. I was prepping a long-ish overview of my problem
to submit, but I think I'll start out with a simple case of the
problem first, hopefully answers I receive will help me solve
my initial issue.
Consider the follow
On 4/13/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 13, 2006 at 06:26:00PM -0700, patrick keshishian wrote:
> > $ dropdb dbname
> > $ createdb dbname
> > $ pg_restore -vsOd dbname dbname.DUMP
>
> That step is pointless, because the next pg_restore
On 4/13/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> "patrick keshishian" <[EMAIL PROTECTED]> writes:
> > With these settings and running:
> > pg_restore -vaOd dbname dbname.DUMP
>
> If you had mentioned you were using random nondefault switches, we&
That's just over 14 minutes!
Ideas?
Is this because the -c option drops all foreign keys and
so the restore goes faster? Should this be the preferred,
recommended and documented method to run pg_restore?
Any drawbacks to this method?
Thanks,
--patrick
On 4/12/06, Tom Lane <[EMAIL PRO
Greetings,
I have 395M pg_dump from a PostgreSQL 7.4.2 database.
This dump is from one of our customer's servers. There is
a web-based administration UI which has been reported to
be extremely slow and unusable.
To see what's going on with their data I have grabbed a
copy of their nightly pg_dum
