Re: Postgresql takes more time to update

From: "Peter Koczan" <pjkoczan(at)gmail(dot)com>
To: "Suresh Gupta VG" <suresh(dot)g(at)zensar(dot)com>
Cc: scott(dot)marlowe(at)gmail(dot)com, pgsql-admin(at)postgresql(dot)org
Subject: Re: Postgresql takes more time to update
Date: 2007-10-08 16:31:10
Message-ID: 4544e0330710080931o31221e62h4bde26bb1c069f29@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On 10/7/07, Suresh Gupta VG <suresh(dot)g(at)zensar(dot)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

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Rodrigo De León 2007-10-08 17:01:19 Re: PL/JAVA ResultSetProvider Problem
Previous Message yogesh 2007-10-08 09:28:41 PL/JAVA ResultSetProvider Problem