Re: Low Performance for big hospital server .. - Mailing list pgsql-performance

From amrit@health2.moph.go.th
Subject Re: Low Performance for big hospital server ..
Date
Msg-id 1105029283.41dd68a3ead99@webmail.moph.go.th
Whole thread Raw
In response to Re: Low Performance for big hospital server ..  (Dawid Kuroczko <qnex42@gmail.com>)
List pgsql-performance
> Ahh, the huge update.  Below are my "hints" I've
> found while trying to optimize such updates.
>
> First of all, does this update really changes this 'flag'?
> Say, you have update:
> UPDATE foo SET flag = 4 WHERE [blah];
> are you sure, that flag always is different than 4?
> If not, then add:
> UPDATE foo SET flag = 4 WHERE flag <> 4 AND [blah];
> This makes sure only tuples which actually need the change will
> receive it.  [ IIRC mySQL does this, while PgSQL will always perform
> UPDATE, regardless if it changes or not ];
>
> Divide the update, if possible.  This way query uses
> less memory and you may call VACUUM inbetween
> updates.  To do this, first SELECT INTO TEMPORARY
> table the list of rows to update (their ids or something),
> and then loop through it to update the values.
>
> I guess the problem with huge updates is that
> until the update is finished, the new tuples are
> not visible, so the old cannot be freed...

Yes, very good point I must try this and I will give you the result , thanks a
lot.
Amrit
Thailand


pgsql-performance by date:

Previous
From: Frank Wiles
Date:
Subject: Re: first postgrreSQL tunning
Next
From: Josh Berkus
Date:
Subject: Re: Benchmark two separate SELECTs versus one LEFT JOIN