Re: Simple DELETE on modest-size table runs 100% CPU forever

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

In response to

Browse pgsql-performance by date

  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