Re: Tips on troubleshooting slow DELETE (suspect cascades)

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: Jim Vanns <jvanns(at)ilm(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Tips on troubleshooting slow DELETE (suspect cascades)
Date: 2024-01-16 17:53:09
Message-ID: 566a6359-940c-457e-b4c6-02cdf00f54f0@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 1/16/24 09:45, Jim Vanns wrote:
> Hi,
>
> I have a slow (CPU bound) DELETE statement I'm attempting to debug and I
> suspect that its actually the ON DELETE CASCADE on the foreign key thats
> causing it. I suspect this because the dry-run mode of the same query (a
> SELECT instead of DELETE) doesn't suffer the same fate. The statement is
> effectively;
>
> # Dry mode
> SELECT prune_function(timestamp);
> # Destructive mode
> DELETE FROM foobar p USING prune_function(timestamp) AS e WHERE p.id
> <http://p.id> = e.prune_id
>
> The logs seem to hold no information on the progress of the statement
> but the CPU is pegged at 100% for hours. The SELECT equivalent runs in
> under a minute.
>
> What I need is a way to see into this statement as it executes to
> confirm my suspicion - does anyone have any tips on that?

Explain:

https://www.postgresql.org/docs/current/sql-explain.html

It would also be helpful to reply with the table definitions for the
tables. If that is not possible then at least whether there is an index
on the FK reference in the child table(s)?

>
> Cheers
>
> Jim
>
> --
> Jim Vanns
> Principal Production Engineer
> Industrial Light & Magic, London

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ron Johnson 2024-01-16 17:54:10 Re: postgres sql assistance
Previous Message Jim Vanns 2024-01-16 17:45:39 Tips on troubleshooting slow DELETE (suspect cascades)