Re: Update is more affected( taking more time) than Select

Поиск
Список
Период
Сортировка
От Richard Huxton
Тема Re: Update is more affected( taking more time) than Select
Дата
Msg-id 43181FDB.7070106@archonet.com
обсуждение исходный текст
Ответ на Update is more affected( taking more time) than Select ( if Auto vacuum is not running)  (Hemant Pandey <hemant.pandey@flextronicssoftware.com>)
Список pgsql-performance
Hemant Pandey wrote:
> Operation A:            6 Fetch + 1 Update
> Operation B:            9 Fetch
> Operation C:            5 Fetch + 3 Update  ( Tables has 140 records)
>
> I have run these operations while Auto Vacumm is running and observed the
> time taken in thse operations. I found that Operation C is taking highest
> time and A is the lowest.
> So i inferrred that, UPDATE takes more time.
>
> Now i run these operations again, without running Auto Vacuum. I observed
> that, time taken for operation A & B is almost same but time for Operation
> C is increasing.
>
> I am not able to analyze, why only for operation C, time is increasing??
> Does auto vacuum affects more on UPDATE.

Depends on what is happening. Without vacuuming (automatic or manual) a
table will tend to have "holes" since an update with MVCC is basically a
delete and an insert.

Since you say the table has only 140 records, almost any operation will
tend to scan rather than use an index. However, if you issue lots of
updates you will end up with many "holes" which have to be scanned past.
PG won't know they are there because its statistics will be out of date
unless you have analysed that table recently. So - everything will start
to get slower.

So - for a small, rapidly updated table make sure you vacuum a lot
(perhaps as often as once a minute). Or, run autovacuum and let it cope.

--
   Richard Huxton
   Archonet Ltd

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

Предыдущее
От: Richard Huxton
Дата:
Сообщение: Re: Avoid using swap in a cluster
Следующее
От: Matteo Beccati
Дата:
Сообщение: ORDER BY and LIMIT not propagated on inherited tables / UNIONs