Have you tried using a TRUNCATE instead of a DELETE ? I've found it to be *way*
faster and has some better aspects with vacuuming the table afterwards.
I am not sure why you would see such a change from 8.0.9 though (we mostly
skipped to 8.1 and now 8.2).
Do you know if the aggregation part has slowed, the delete part, or both ? If
they were to take much longer than they used to I would expect that the
attaching processes would experience unhappiness. Can you do an explain analyze
on both the old and new systems ?
HTH,
Greg Williamson
DBA
GlobeXPlorer LLC, a DigitalGLobe company
Confidentiality Notice: This e-mail message, including any attachments, is for
the sole use of the intended recipient(s) and may contain confidential and
privileged information and must be protected in accordance with those
provisions. Any unauthorized review, use, disclosure or distribution is
prohibited. If you are not the intended recipient, please contact the sender by
reply e-mail and destroy all copies of the original message.
-----Original Message-----
From: [EMAIL PROTECTED] on behalf of David F. Skoll
Sent: Thu 1/18/2007 5:37 PM
To: pgsql-admin@postgresql.org
Cc:
Subject: [ADMIN] Strange performance hit upgrading from 8.0.9 to 8.2.1
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
-------------------------------------------------------
Click link below if it is SPAM [EMAIL PROTECTED]
"https://mailscanner.globexplorer.com/dspam/dspam.cgi?signatureID=45b026ea317331465134470&[EMAIL
PROTECTED]&retrain=spam&template=history&history_page=1"
!DSPAM:45b026ea317331465134470!
-------------------------------------------------------
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
