Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eMHmt-0003Vu-Gk for pgsql-performance@arkaria.postgresql.org; Tue, 05 Dec 2017 18:17:47 +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 1eMHmt-0000eT-3q for pgsql-performance@arkaria.postgresql.org; Tue, 05 Dec 2017 18:17:47 +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 1eMHms-0000eK-Tb for pgsql-performance@lists.postgresql.org; Tue, 05 Dec 2017 18:17:46 +0000 Received: from mail-qt0-x244.google.com ([2607:f8b0:400d:c0d::244]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eMHmp-0007D5-1V for pgsql-performance@lists.postgresql.org; Tue, 05 Dec 2017 18:17:46 +0000 Received: by mail-qt0-x244.google.com with SMTP id k19so2944068qtj.6 for ; Tue, 05 Dec 2017 10:17:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=bxXPkO+3PKCXBETjdMJ6owFAFFYnPYzNUFe7Z47e7x4=; b=ceVtwHZWXGyToOSWPwVynFS2OukUjApDjya/LMBQQA3zmPeGbzoQVTO0AxkaWlnSA+ MgyuC021w3xxZwuiO+2gUiMaB64aT16Yp+AdX47xobwIV9sn6cgh3rQ6Q/3REMuhCxWP DeJBUtKY+owvfrHwQqq6wYbfQlnCe3t4y+p+M5Ow5cT+r+f1sfx8/HeL64YSwnmpNHkG pj9NRYu0xaUzGAX7uhFGOzK9DAKUHWlHssLRW1SVc+POEnYL2HT0U16SqhWV/5MS9C64 SzIQiJR2rAjQHgAwE4XxkcTvrR2MyxS0lFKo/mxuPi1B9GEYO64kGSFFGGuche+k5tMQ hdxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=bxXPkO+3PKCXBETjdMJ6owFAFFYnPYzNUFe7Z47e7x4=; b=aMH983NZ1jHgCV1TZbjdf2yRHITlaMx9tWuYQ1whAy9/c2V4Sn355bMt+e0cu+CJg6 VD3e65ufYmz7vHBeMafC3NG3NT5fa8h4/VuQzHf2A8r0IgB3T2f25M9kLyZh6EiXvvPS qBLaSdHdNS/uSByUT7QOvnSTuGR3DNZkB7RHB3EYWwWNlCd1NmS20fPG5OAPdrceK/Gr kIjII+NF5Wd3mBqDcI9Hdaoi8LIX/USVehmWfS1V4P0SpLAyAJOU7Zf5yklPK0w58T+g AfieAQ7mEVV6ld2EzRx7nh/UWOpocFLBGO1jz52CGI17966m255OtO5IoErdCFz4BDKR suWA== X-Gm-Message-State: AKGB3mLGePDIyY8dxjqAg4kJT2wKZykIK+RIXWw0AXYUJxqKpfLOuT7q KOQkTpUtINm3DruJn7whE2ZFUg== X-Google-Smtp-Source: AGs4zMaj/ka3otJqNiwbtXp3VXSv8VF2ERjn5p+vRdEQM1IWfgrtbKf9iXuDn8lpzmwIUbXFZ/jKcg== X-Received: by 10.55.215.22 with SMTP id m22mr2506200qki.91.1512497860713; Tue, 05 Dec 2017 10:17:40 -0800 (PST) Received: from [192.168.1.6] ([181.213.88.188]) by smtp.gmail.com with ESMTPSA id p8sm421275qtj.70.2017.12.05.10.17.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Dec 2017 10:17:40 -0800 (PST) Subject: Re: Extremely slow DELETE with cascade foreign keys From: Rodrigo Rosenfeld Rosas To: Alvaro Herrera Cc: Tom Lane , pgsql-performance@lists.postgresql.org References: <20171205174914.7q4x56gii3f626zg@alvherre.pgsql> <833f6794-3a02-ca8a-5c95-3f1bcaf686b4@gmail.com> Message-ID: <49f698a3-e4f3-d4e4-f769-d29b39bbb735@gmail.com> Date: Tue, 5 Dec 2017 16:17:35 -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: <833f6794-3a02-ca8a-5c95-3f1bcaf686b4@gmail.com> 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 16:15, Rodrigo Rosenfeld Rosas escreveu: > Em 05-12-2017 15:49, Alvaro Herrera escreveu: >> Rodrigo Rosenfeld Rosas wrote: >>> Em 05-12-2017 15:25, Tom Lane escreveu: >>>>> 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? >>> Yes, I was also hoping to get more insights through the EXPLAIN >>> output :) >> It normally does.  Can you show \d of the table containing the FK? > > \d highlighted_text >                                          Tabela "public.highlighted_text" >     Coluna    |            Tipo             | Collation | Nullable > |                   Default > --------------+-----------------------------+-----------+----------+---------------------------------------------- > >  id           | integer                     |           | not null | > nextval('highlighted_text_id_seq'::regclass) >  date_created | timestamp without time zone |           | not null | >  last_updated | timestamp without time zone |           | not null | >  reference_id | integer                     |           | not null | >  highlighting | text                        |           | | > Índices: >     "highlighted_text_pkey" PRIMARY KEY, btree (id) >     "highlighted_text_reference_id_idx" btree (reference_id) > Restrições de chave estrangeira: >     "fk_highlighted_text_reference" FOREIGN KEY (reference_id) > REFERENCES "references"(id) ON DELETE CASCADE > > The highlighted_text_reference_id_idx was previously missing. > > begin; explain analyze delete from "references" where id=966539; > rollback; > BEGIN > Tempo: 0,466 ms >                                                              QUERY PLAN > ------------------------------------------------------------------------------------------------------------------------------------ > >  Delete on "references"  (cost=0.43..8.45 rows=1 width=6) (actual > time=2.683..2.683 rows=0 loops=1) >    ->  Index Scan using references_pkey on "references" > (cost=0.43..8.45 rows=1 width=6) (actual time=2.609..2.612 rows=1 > loops=1) >          Index Cond: (id = 966539) >  Planning time: 0.186 ms >  Trigger for constraint fk_highlighted_text_reference: time=0.804 calls=1 >  Execution time: 3.551 ms > (6 registros) > > Tempo: 4,791 ms > ROLLBACK > Tempo: 0,316 ms > > drop index highlighted_text_reference_id_idx; > DROP INDEX > Tempo: 35,938 ms > > begin; explain analyze delete from "references" where id=966539; > rollback; > BEGIN > Tempo: 0,494 ms >                                                              QUERY PLAN > ------------------------------------------------------------------------------------------------------------------------------------ > >  Delete on "references"  (cost=0.43..8.45 rows=1 width=6) (actual > time=0.112..0.112 rows=0 loops=1) >    ->  Index Scan using references_pkey on "references" > (cost=0.43..8.45 rows=1 width=6) (actual time=0.071..0.074 rows=1 > loops=1) >          Index Cond: (id = 966539) >  Planning time: 0.181 ms >  Trigger for constraint fk_highlighted_text_reference: time=2513.816 > calls=1 >  Execution time: 2513.992 ms > (6 registros) > > Time: 2514,801 ms (00:02,515) > ROLLBACK > Tempo: 0,291 ms > > It displayed the spent on the trigger this time. How about deleting > the field values? > > begin; explain analyze delete from field_values where > transaction_id=2479; rollback; > BEGIN > Tempo: 0,461 ms > QUERY PLAN > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > >  Delete on field_values  (cost=0.43..364.98 rows=453 width=6) (actual > time=4.732..4.732 rows=0 loops=1) >    ->  Index Scan using index_field_values_on_transaction_id on > field_values (cost=0.43..364.98 rows=453 width=6) (actual > time=0.137..0.949 rows=624 loops=1) >          Index Cond: (transaction_id = 2479) >  Planning time: 0.210 ms >  Trigger for constraint field_value_booleans_field_value_id_fkey on > field_values: time=7.953 calls=624 >  Trigger for constraint field_value_currencies_field_value_id_fkey on > field_values: time=5.548 calls=624 >  Trigger for constraint field_value_jurisdictions_field_value_id_fkey > on field_values: time=6.376 calls=624 >  Trigger for constraint fk_field_value_date_range_field_value_id on > field_values: time=5.735 calls=624 >  Trigger for constraint fk_field_value_dates_field_value_id on > field_values: time=6.316 calls=624 >  Trigger for constraint fk_field_value_numerics_field_value_id on > field_values: time=6.368 calls=624 >  Trigger for constraint fk_field_value_options_field_value_id on > field_values: time=6.503 calls=624 >  Trigger for constraint fk_field_value_strings_field_value_id on > field_values: time=6.794 calls=624 >  Trigger for constraint fk_field_value_time_spans_field_value_id on > field_values: time=6.332 calls=624 >  Trigger for constraint fk_references_field_value_id on field_values: > time=7.382 calls=624 >  Trigger for constraint fk_highlighted_text_reference on references: > time=644994.047 calls=390 >  Execution time: 645065.326 ms > (16 registros) > > Time: 645066,726 ms (10:45,067) > ROLLBACK > Tempo: 0,300 ms > > Yeah, for some reason, now I got the relevant trigger hints :) Go > figure out why it didn't work the last time I tried before subscribing > to this list :) > > Glad it's working now anyway :) Just in case you're curious, creating the index took 6s and running the same delete this time only took 75ms with the index in place :)