Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id 7C682F6498F for ; Tue, 24 Jul 2012 11:54:49 -0300 (ADT) Received: from plane.gmane.org ([80.91.229.3]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1StgVb-0001gb-N3 for pgsql-performance@postgresql.org; Tue, 24 Jul 2012 14:54:48 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1StgVO-0007mv-GE for pgsql-performance@postgresql.org; Tue, 24 Jul 2012 16:54:34 +0200 Received: from 217.110.94.67 ([217.110.94.67]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Jul 2012 16:54:34 +0200 Received: from spam_eater by 217.110.94.67 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Jul 2012 16:54:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: pgsql-performance@postgresql.org From: Thomas Kellerer Subject: Re: Using ctid column changes plan drastically Date: Tue, 24 Jul 2012 16:54:18 +0200 Lines: 23 Message-ID: References: <21308.1343139781@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 217.110.94.67 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 In-Reply-To: <21308.1343139781@sss.pgh.pa.us> X-Pg-Spam-Score: -0.7 (/) X-Archive-Number: 201207/302 X-Sequence-Number: 47483 Tom Lane, 24.07.2012 16:23: > Thomas Kellerer writes: >> DELETE FROM dupes >> WHERE id NOT IN (SELECT min(b.id) >> FROM dupes b >> GROUP BY first_name, last_Name >> HAVING count(*) > 1); > > Doesn't that kill the non-duplicates too? Ah right - another good point on how important the correct test data is ;) >> Why does the usage of the CTID column change the plan so drastically? > > IIRC, type tid doesn't have any hash support. > So the "bad" plan is expected? Regards Thomas