Thread: Copy of DB behaves different from original

Copy of DB behaves different from original

From
jason@soundconcept.net
Date:
Hi all,

I have a database that I made a copy of (useing pg_dump) to test a new
program on.  The program runs just fine on the new(copy) database.  However,
when I switched my program to run on my old(original) database it runs
around 10 times slower and takes up way more processor power.  I tried
vacuumdb on the old database and it made no difference.  Any idea what my
problem might be?  I could just drop and restore the old database, but I
would really like to understand what might be going on so I could watch for
it in the future and hopefully prevent it from happening again.

Any information is greatly appreciated.

Jason Haselbauer
Soundconcept.net
jason@soundconcept.net



Re: Copy of DB behaves different from original

From
Steve Crawford
Date:
On Wednesday 01 September 2004 1:59 pm, jason@soundconcept.net wrote:
> Hi all,
>
> I have a database that I made a copy of (useing pg_dump) to test a
> new program on.  The program runs just fine on the new(copy)
> database.  However, when I switched my program to run on my
> old(original) database it runs around 10 times slower and takes up
> way more processor power.  I tried vacuumdb on the old database and
> it made no difference.  Any idea what my problem might be?  I could
> just drop and restore the old database, but I would really like to
> understand what might be going on so I could watch for it in the
> future and hopefully prevent it from happening again.
>
> Any information is greatly appreciated.

If the original database isn't live then try a vacuum full on the old
database and be sure to analyze it as well (vacuumdb --full
--analyze). The standard vacuum does not physically shrink the
database files - it just makes no longer used space within the file
available for reuse. The --analyze will update the statistics the
planner uses when deciding how to approach the query (mainly use of
indexes).

 If that doesn't do the trick, try reindexing the tables.

Cheers,
Steve