Re: Low Performance for big hospital server ..

Поиск
Список
Период
Сортировка
От amrit@health2.moph.go.th
Тема Re: Low Performance for big hospital server ..
Дата
Msg-id 1105029283.41dd68a3ead99@webmail.moph.go.th
обсуждение исходный текст
Ответ на Re: Low Performance for big hospital server ..  (Dawid Kuroczko <qnex42@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Frank Wiles
Дата:
Сообщение: Re: first postgrreSQL tunning
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Benchmark two separate SELECTs versus one LEFT JOIN