updates way slower than selects?

Поиск
Список
Период
Сортировка
От Marek Pętlicki
Тема updates way slower than selects?
Дата
Msg-id 20010403161232.A5976@marek.almaran.home
обсуждение исходный текст
Список pgsql-general
Hi!

I've got a question: has anybody noticed in your production
tables, that updates on existing rows take longer than inserts
into those same tables?

I work on an Internet auction system. We have 'items' put to
auction with 'autorestore' option. When such an auction is ended
without solution (I mean: nobody bought the item either because
of not achieving min. price or because of no offers at all)
it can be reentered automatically. It is done by a special
script running on the server.

I mark those auctions to be autorestored by a flag auto_restore int4
auto_restore = 1 means 'autorestore on' (option active)
auto_restore = -1 means 'autorestore pending'

when in autorestore loop I simply select all the auctions with
auto_restore = -1, reinsert those items into the database and update
the column to auto_restore = 1

The timings are very discouraging though - I have timings of insert
vs update like 1:5. It means I insert new auction in 1ms and the
update of the flag takes 5ms. So I have 500% waste of time because of
the method!

This is not a big issue, because I can use additional table
autorestore_pending (consisting of only the IDs of auctions to be
restored) and skip the 'insert / update' routine (changing it into
insert / delete one), but it is not very good news to me
(I have other procedures where I have to massively update the auctions
table and some of them are quite time-critical for the system)



Can someone give me some hint? Do you experience the same effect?
Is it 'normal'? If the answer is 'yes' I will have to look for
solutions avoiding updates on the database.


I use PostgreSQL 7.0.3 with Python 2.0 and PoPy combination
on RH 7.0 (Debian on production machine) on 2.4.x kernel
The mentioned table has a few triggers attached and 16 indices
(it is 30-column table of items in auction - to be sorted multiple
ways and selected on multiple conditions). 3 triggers attached to
'INSERT' and 'UPDATE' are used to provide statistical information
(for the application as well as for the users). But I think
that triggers are not the problem here, because the same ones
are used for 'insert' and for 'update'.


regards and best wishes

--
Marek Pętlicki
marpet@linuxpl.org


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

Предыдущее
От: 100.179370@germanynet.de (Martin Jacobs)
Дата:
Сообщение: Re: PostGreSQL 7.0.3 hangs in SuSE
Следующее
От: "Marcin Wasilewski"
Дата:
Сообщение: Startup script