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

From: Richard Huxton <dev(at)archonet(dot)com>
To: Hemant Pandey <hemant(dot)pandey(at)flextronicssoftware(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Update is more affected( taking more time) than Select
Date: 2005-09-02 09:48:11
Message-ID: 43181FDB.7070106@archonet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Matteo Beccati 2005-09-02 10:20:57 ORDER BY and LIMIT not propagated on inherited tables / UNIONs
Previous Message Richard Huxton 2005-09-02 09:42:59 Re: Avoid using swap in a cluster