From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Craig James <cjames(at)emolecules(dot)com> |
Cc: | pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: Simple DELETE on modest-size table runs 100% CPU forever |
Date: | 2019-11-14 22:28:45 |
Message-ID: | 20191114222845.GW2923@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, Nov 14, 2019 at 02:19:51PM -0800, Craig James wrote:
> I'm completely baffled by this problem: I'm doing a delete that joins three
> modest-sized tables, and it gets completely stuck: 100% CPU use forever.
> Here's the query:
>
> explain analyze
> select count(1) from registry.categories
> where category_id = 15 and id in
> (select c.id from registry.categories c
> left join registry.category_staging_15 st on (c.id = st.id) where
> c.category_id = 15 and st.id is null);
>
> If I leave out the "analyze", here's what I get (note that the
Do you mean that you're doing DELETE..USING, and that's an explain for SELECT
COUNT() with same join conditions ? Can you show explain for the DELETE, and
\d for the tables ?
If there's FKs, do the other tables have indices on their referencING columns ?
https://www.postgresql.org/docs/devel/static/ddl-constraints.html#DDL-CONSTRAINTS-FK
"Since a DELETE of a row from the referenced table [...] will require a scan of
the referencing table for rows matching the old value, it is often a good idea
to index the referencing columns too."
Justin
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2019-11-14 22:29:29 | Re: Simple DELETE on modest-size table runs 100% CPU forever |
Previous Message | Michael Lewis | 2019-11-14 22:24:47 | Re: Simple DELETE on modest-size table runs 100% CPU forever |