Hello,
We have a customer running a rather large installation. There are
about 15 machines talking to a PostgreSQL database server. At any
given time, each machine has between around 20 to 120 connections to
the PG server, and the aggregate query rate probably hovers at over
1000 per second.
Our database has a table that looks like this:
database=> \d low_contention_stats
Table "public.low_contention_stats"
Column | Type | Modifiers
-----------+---------+-----------------------------
date | date | default ('now'::text)::date
key | text |
increment | integer | default 1
There are no indexes on that table. Anywhere from 40 to 100
times per second, we insert something like this into the table:
INSERT INTO low_contention_stats(key, increment) VALUES('ACCEPTED', 1);
The INSERTs run outside of any transaction (ie, in their own self-contained
transaction.) The "key" data being inserted is short -- under 25 characters.
We periodically do something like this:
BEGIN;
-- Aggregate the low_contention data into another table
-- and then...
DELETE FROM low_contention_stats;
COMMIT;
and it used to work fine. However, on the upgrade from 8.0.9 to
8.2.1, we suddenly started seeing terrible performance on the INSERTs.
(The aggregation process was disabled -- we were only doing the
INSERTs at the time.) What would happen is that hundreds of back-ends
would acquire locks on the table and it would take many seconds for
all the INSERTs to finish. Things would settle down for a few seconds
to a couple of minutes, and then again - WHAM! Huge contention.
Disabling the INSERTs completely made everything happy, even though
they formed only a small portion of the overall queries. While this
is OK as a stopgap, it's not really a long-term solution because it
disables a fairly useful feature of our software.
Unfortunately, I have no idea how to duplicate the problem in our
lab with the hardware we have access to. :-( Any PostgreSQL gurus
have any insights?
Regards,
David.
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
