Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eMH0P-0000Nj-Pp for pgsql-performance@arkaria.postgresql.org; Tue, 05 Dec 2017 17:27:41 +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 1eMH0P-0002HC-3O for pgsql-performance@arkaria.postgresql.org; Tue, 05 Dec 2017 17:27:41 +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 1eMH0O-0002H1-T7 for pgsql-performance@lists.postgresql.org; Tue, 05 Dec 2017 17:27:40 +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 1eMH0J-00061l-FD for pgsql-performance@lists.postgresql.org; Tue, 05 Dec 2017 17:27:40 +0000 Received: by mail-qt0-x242.google.com with SMTP id 33so2607214qtv.1 for ; Tue, 05 Dec 2017 09:27:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=kROuWwXiMowE0kSpIvL7RXdoTfzPOOMCRvFAr0ywZ20=; b=JGwotFS+oL51vadpD69V2sdSnaQgyrf66+GonBAvFk464U++HFe/CMmJoTlQXz/ZHL 6yOVBgK4pbzcVW7bI8YNHDyn4fMAznWpHEEoC6zaMFFP1+IC1pBYWceer7VlGs9S1Fmf Au8a7t4tIbp7+58VC+UlCv+0N/1cow+jjLKGq5iZ8o3r7YzSfMrZ3E9/dN4gpSe63agI Vyh8jtJX4Gkwoy3kpb4KC97g05W2tHjlwlYViW+YJbgzVP2MEwy9DsErOrfryIVxDmgJ RwpYhn6UU9/zjplf/bFw9qIkE9nVlp4OpJFEYWENEC2jXHtVmVWLbdoOMc1EGZahyjAG Iw+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=kROuWwXiMowE0kSpIvL7RXdoTfzPOOMCRvFAr0ywZ20=; b=KKQ9rTkzeao3+84znNfbSV+dUQorr+4Y7ooR7TUzQYZXIJ0o+bAM12DbzzxbrGK23G +b/acgPBmWj+lcXRBySiS4OgONSQkYPa10PMFjZWxX8BgfLnPqIAji4j6hzpAtmoV4w2 2tfSepW8SRluc/9rib+KEa2Wav+JRkmGl48PQYJMK1CDt8Gr1sgpFhWiD2Nn3ZkRCSig cvK13Pd1madOtmT/KbECmmZLn9vgEMDV8uKKU24hruGXy3/cU2pUOlJply9eEcWToxMA 4pTrIJQ90zRyLF8ZlsgphgEijrFVJbA1vpIxptQCpq0W8CdjBr4QfNu9t1hWPkYVolS6 DG1Q== X-Gm-Message-State: AKGB3mL16nf542XkiRiWvAX7NSPtF3jN6u7hNRwZ6xbzmYtsE0+XMZH1 LFo/1fO2vJ5anystyc8OQL0rNQ== X-Google-Smtp-Source: AGs4zMbwAN7dbecC709KiONf8wgj1ayCJFp9h+fryn6gJxM70ZQALPVB2599fSd51MYGcYjM8x2+XA== X-Received: by 10.55.164.147 with SMTP id n141mr22945663qke.277.1512494853403; Tue, 05 Dec 2017 09:27:33 -0800 (PST) Received: from [192.168.1.6] ([181.213.88.188]) by smtp.gmail.com with ESMTPSA id a195sm398386qkb.23.2017.12.05.09.27.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Dec 2017 09:27:32 -0800 (PST) Subject: Re: Extremely slow DELETE with cascade foreign keys To: Tom Lane , Alvaro Herrera Cc: pgsql-performance@lists.postgresql.org References: <20171205164328.6t4w3abfpzp54y2y@alvherre.pgsql> <10850.1512494726@sss.pgh.pa.us> From: Rodrigo Rosenfeld Rosas Message-ID: <734f6343-35f6-1d1d-3fd7-87e1a1dea9da@gmail.com> Date: Tue, 5 Dec 2017 15:27:28 -0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <10850.1512494726@sss.pgh.pa.us> 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 Em 05-12-2017 15:25, Tom Lane escreveu: > Alvaro Herrera writes: >> Rodrigo Rosenfeld Rosas wrote: >>> 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) >> Normally this is because you lack indexes on the referencing columns, so >> the query that scans the table to find the referencing rows is a >> seqscan. > Actually though ... the weird thing about this is that I'd expect to > see a separate line in the EXPLAIN output for time spent in the FK > trigger. Where'd that go? > > regards, tom lane Yes, I was also hoping to get more insights through the EXPLAIN output :)