Re: Low Performance for big hospital server ..

Поиск
Список
Период
Сортировка
От Dawid Kuroczko
Тема Re: Low Performance for big hospital server ..
Дата
Msg-id 758d5e7f050106041510f07dc5@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Low Performance for big hospital server ..  (amrit@health2.moph.go.th)
Ответы Re: Low Performance for big hospital server ..
Re: Low Performance for big hospital server ..
Список pgsql-performance
On Wed,  5 Jan 2005 22:35:42 +0700, amrit@health2.moph.go.th
<amrit@health2.moph.go.th> wrote:
> Now I turn hyperthreading off and readjust the conf . I found the bulb query
> that was :
> update one flag of the table [8 million records which I think not too much]

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...

   Regards,
      Dawid

В списке pgsql-performance по дате отправления:

Предыдущее
От: Ben Bostow
Дата:
Сообщение: Problems with high traffic
Следующее
От: Dave Cramer
Дата:
Сообщение: Re: Problems with high traffic