Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TK9sS-0003uS-B4 for pgsql-performance@postgresql.org; Fri, 05 Oct 2012 15:31:48 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TK9sQ-00080z-Jn for pgsql-performance@postgresql.org; Fri, 05 Oct 2012 15:31:48 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id q95FVhwb009896; Fri, 5 Oct 2012 11:31:43 -0400 (EDT) From: Tom Lane To: Maciek Sakrejda cc: Claudio Freire , Jeff Janes , Anibal David Acosta , pgsql-performance@postgresql.org Subject: Re: how to avoid deadlock on masive update with multiples delete In-reply-to: References: <005701cda238$ba4d0350$2ee709f0$@devshock.com> Comments: In-reply-to Maciek Sakrejda message dated "Fri, 05 Oct 2012 08:08:19 -0700" Date: Fri, 05 Oct 2012 11:31:43 -0400 Message-ID: <9895.1349451103@sss.pgh.pa.us> X-Pg-Spam-Score: -4.0 (----) X-Archive-Number: 201210/29 X-Sequence-Number: 47988 Maciek Sakrejda writes: > Presumably something like this?: > maciek=# CREATE TABLE test AS SELECT g, random() FROM > generate_series(1,1000) g; > CREATE > maciek=# EXPLAIN DELETE FROM test USING (SELECT g FROM test ORDER BY > ctid) x where x.g = test.g; There's no guarantee that the planner won't re-sort the rows coming from the sub-select, unfortunately. regards, tom lane