Re: Postgresql takes more time to update
Hi Peter,
1) We are using "psql 7.4.2" version of Postgresql, need to create a new schema similar to the current schema with all the objects as in the current schema. Do we have any command to support this operation.
2) We need to shift all the data between 2 different databases in 2 different servers. What is the best way to go either backup or copy command?
Can you please give some knowledge on this.
with thanks and regards,
G.V. Suresh Gupta
Sr. Software Engineer
Batelco Phase II
Mo: +91 9890898688
Ph : +9120 66453213
From: Peter Koczan [mailto:pjkoczan@gmail.com]
Sent: Monday, October 08, 2007 10:01 PM
To: Suresh Gupta VG
Cc: scott.marlowe@gmail.com; pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Postgresql takes more time to update
On 10/7/07, Suresh Gupta VG <suresh.g@zensar.com> wrote:
Hi Peter,
Thanks for your reply and to your colleague Scott. Can you pls explain below sentence marked in red.
- --------- ------------------ ---------------------
As an alternative to Scott's suggestion (upgrading to the newest 7.4), you could update your postgresql installation to 8.2, or if you can wait a few months, 8.3. There are *huge* performance gains (I recently made a similar switch and everything is blazing fast). Please note that this will require a dump/restore of the data and more involved testing, so only do it if you can devote the time, money, and energy.
- --------- ---------------- ------------- --------------
Is 8.2 version is not free downloadable? What type of testing is required? Pls advice us.
Sorry about being ambiguous, 8.2 is still free, but it does have quite a few changes from 7.4, so it will take time to update your configuration, recompile/reinstall postgres, dump/restore your data, and test your client applications. This will take time for the IT staff to do (and therefore money). This is what I meant by "devoting money".
Specifically, when I upgraded, I ran into these problems:
- A primary key broke and I had to fix it before going ultimately migrating to 8.2.
- The cidr data type is more strictly checked, I had to fix a couple rows before migrating.
- Permissions and ownership underwent slight changes.
- User and groups were conflated into roles, which necessitated a change in my user/group management scripts.
I tested these thoroughly before making the migration final. I found most of these problems from a simple dump/restore. If you can, dump and restore your databases to a test server (insofar as you can) and you should be able to fix most migration issues.
The last thing you'll want to do is test your more critical client applications. Postgres is very good about maintaining backwards compatibility of SQL, so most things should "just work." Still, test.
Peter
DISCLAIMER:
This email may contain confidential or privileged information for the intended recipient(s) and the views expressed in the same are not necessarily the views of Zensar Technologies Ltd. If you are not the intended recipient or have received this e-mail by error, its use is strictly prohibited, please delete the e-mail and notify the sender. Zensar Technologies Ltd. does not accept any liability for virus infected mails.
Вложения
В списке pgsql-admin по дате отправления: