Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eMFyl-0004XA-4Z for pgsql-performance@arkaria.postgresql.org; Tue, 05 Dec 2017 16:21:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eMFyi-0006mv-IL for pgsql-performance@arkaria.postgresql.org; Tue, 05 Dec 2017 16:21:52 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eMFyi-0006mj-8y for pgsql-performance@lists.postgresql.org; Tue, 05 Dec 2017 16:21:52 +0000 Received: from mail-qt0-x242.google.com ([2607:f8b0:400d:c0d::242]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eMFyd-0004be-6a for pgsql-performance@lists.postgresql.org; Tue, 05 Dec 2017 16:21:51 +0000 Received: by mail-qt0-x242.google.com with SMTP id g9so2001641qth.9 for ; Tue, 05 Dec 2017 08:21:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=ecrCY/P9iGAAw+oN61rM8aHuJYwJVdT7nKls1ZXqzKk=; b=uOSO890lwfcVZYesPS0OKWjKdMKwSQvN6xqUzQNcEhgfxz0S1+6Ysr/e03+ZRxeOAa uCSY7jYswTEymn6JuEDc9DysdOt9hjb5gNZJblrIx1gBwjKEiPxucSP6N0Ay5xGQpikD +dhy7LIjWWdiHU+Q4VECMPIueD40Io2Fwk2uJiVx+RHuYJ08PRZMNvj3n2/7Al+RLGr7 pro7uZualix5kN1yCXas+Cv0UnijJRwFd4ZNWMlLvse7cb6Qwu/Wf/1SWnYjjqG6CCxn wY1D0TpYxcuPJ2pWOqAZr2ESI2qDJcatUbFGkj6D3jCcMArpMCE6r2UJ7oSe9/VDYidT L41g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=ecrCY/P9iGAAw+oN61rM8aHuJYwJVdT7nKls1ZXqzKk=; b=elB30n3rQsOU0YL47hyKC4xlNaPfYjh7zVHqVmfapeWK+yG5/NujKZL6u/Fl7y/mGh PlgdvrZqdvhckSsvnlEi2a1eQjU5ipXDjPwk5DkewAoLlOe0+mbUq/gdip2sTofdrJjo lHUz4W+VFf7m1esi50MzwKiwUuhs9DGYIobrXPcduN8OG9pn2a9OQdXyIE9mBViyzKIy sbjChkzogbqAVz5KxbqHgwzl6BBxalNK+rkdeaDkUiQp5paAT9EM1N30AlPbN6E0lIW4 2NNIN1gX9+lBfZNLcWP/J3cAicG1h0kvE2Z+aTo8aDTQe4mKRSM/idNVY1s8kX/Ya6Pu TXKg== X-Gm-Message-State: AKGB3mKyQd6YR7EKbQYAMEF7BH4KN1obPOU/GGCtxpQwT8HCVlhPsMoZ guK8r9kTm2z/ygBxBkxGnKZHkA== X-Google-Smtp-Source: AGs4zMYqwn82x0afUjHq9dXPKK+dEgIQItL8JW0aYP2eTYjvVf9Dj95CH0LsS1Z+3tZvYgk/uNnCXA== X-Received: by 10.200.28.44 with SMTP id a41mr2690922qtk.340.1512490904033; Tue, 05 Dec 2017 08:21:44 -0800 (PST) Received: from [192.168.1.6] ([181.213.88.188]) by smtp.gmail.com with ESMTPSA id k51sm325460qtc.33.2017.12.05.08.21.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Dec 2017 08:21:43 -0800 (PST) To: pgsql-performance@lists.postgresql.org From: Rodrigo Rosenfeld Rosas Subject: Extremely slow DELETE with cascade foreign keys Message-ID: <8f569ed9-fde9-1fe7-4beb-01945009e040@gmail.com> Date: Tue, 5 Dec 2017 14:21:38 -0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: pt-BR List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, I think something changed recently in my development environment as I don't recall deletes being so slow before. I've created a new dump and restored to a new database, ran VACUUM FULL ANALYSE and a simple delete takes forever as you can see here: explain analyze delete from field_values where transaction_id=226; QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------------------------------------  Delete on field_values  (cost=0.43..257.93 rows=481 width=6) (actual time=367375.805..367375.805 rows=0 loops=1)    ->  Index Scan using index_field_values_on_transaction_id on field_values  (cost=0.43..257.93 rows=481 width=6) (actual time=0.223..4.216 rows=651 loops=1)          Index Cond: (transaction_id = 226)  Planning time: 0.234 ms  Execution time: 367375.882 ms (5 registros) Time: 367377,085 ms (06:07,377) Any ideas on what could be causing this? Could it be an issue with my hard drive? There aren't that many records to delete from the other tables referencing field_values. I've done this sort of operation earlier this year and it was quite fast. Any clues? Thanks in advance, Rodrigo.