From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | Jie Liang <jie(at)stbernard(dot)com> |
Cc: | "'pgsql-admin(at)postgresql(dot)org'" <pgsql-admin(at)postgresql(dot)org>, "'pgsql-hacker(at)postgresql(dot)org'" <pgsql-hacker(at)postgresql(dot)org> |
Subject: | Re: pg_restore weirdness |
Date: | 2002-08-06 17:29:39 |
Message-ID: | 20020806102721.S84890-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Tue, 6 Aug 2002, Jie Liang wrote:
> I got a very weird restore problem:
> 1. I use
> pg_dump -Fc urldb > urldb
> on one server(FreeBSD4.3 Pg7.2.0)
> 2. I use
> pg_restore -l urldb > archive.list
> on another server(FreeBSD4.6 Pg7.2.1)
> then I use
> pg_restore -v -L archive.lst -d urldb urldb
> on this server(Pg7.2.1)
> 3. I vacuum tables, then run my sql function which was written in plpgsql
> very simple, I got very surprised is that it run much slower on Pg7.2.1
> machine then Pg7.2.0 machine!
> 4. When I dropped this function and reload it again(still in binary), it
> much much faster then before.
>
> I tested serveral times, same conclusion, I have no other backend running
> there.
> I cannot explain this, and it doesn't make any sence to me also!
You haven't shown us codestr(). Is it possible that it's a plpgsql
function that accesses a table and that it was called in your session
prior to the analyze? If so, it may have cached a less optimal query
plan. If that were true then quiting your session and starting a new one
would have also made it faster.
From | Date | Subject | |
---|---|---|---|
Next Message | Jie Liang | 2002-08-06 18:13:32 | Re: pg_restore weirdness |
Previous Message | Jie Liang | 2002-08-06 17:20:25 | pg_restore weirdness |