From: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
---|---|
To: | Martin Nickel <martin(at)portant(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: How can this be? |
Date: | 2005-09-19 23:07:44 |
Message-ID: | 20050919160622.F99507@megazone.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Fri, 16 Sep 2005, Martin Nickel wrote:
> Hello all,
> Mostly Postgres makes sense to me. But now and then it does something
> that boggles my brain. Take the statements below. I have a table
> (agent) with 5300 rows. The primary key is agent_id. I can do SELECT
> agent_id FROM agent and it returns all PK values in less than half a
> second (dual Opteron box, 4G ram, SATA Raid 10 drive system).
>
> But when I do a DELETE on two rows with an IN statement, using the primary
> key index (as stated by EXPLAIN) it take almost 4 minutes.
> pg_stat_activity shows nine other connections, all idle.
Are there any tables that reference agent or other triggers? My first
guess would be that there's a foreign key check for something else that's
referencing agent.agent_id for which an index scan isn't being used.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-09-20 03:05:41 | Re: Index Selection: ORDER BY vs. PRIMARY KEY |
Previous Message | Steve Atkins | 2005-09-19 23:02:09 | Re: How can this be? |