Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125])
	by mail.postgresql.org (Postfix) with ESMTP id BCE69F6498E
	for <pgsql-performance@postgresql.org>;
	Tue, 24 Jul 2012 11:23:18 -0300 (ADT)
Received: from sss.pgh.pa.us ([66.207.139.130])
	by makus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <tgl@sss.pgh.pa.us>) id 1Stg17-00015i-T9
	for pgsql-performance@postgresql.org; Tue, 24 Jul 2012 14:23:18 +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 q6OEN1OJ021309;
	Tue, 24 Jul 2012 10:23:01 -0400 (EDT)
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Kellerer <spam_eater@gmx.net>
cc: pgsql-performance@postgresql.org
Subject: Re: Using ctid column changes plan drastically
In-reply-to: <julsfr$otg$1@dough.gmane.org>
References: <julsfr$otg$1@dough.gmane.org>
Comments: In-reply-to Thomas Kellerer <spam_eater@gmx.net>
	message dated "Tue, 24 Jul 2012 12:13:09 +0200"
Date: Tue, 24 Jul 2012 10:23:01 -0400
Message-ID: <21308.1343139781@sss.pgh.pa.us>
X-Pg-Spam-Score: -1.9 (-)
X-Archive-Number: 201207/297
X-Sequence-Number: 47478

Thomas Kellerer <spam_eater@gmx.net> 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?

> Why does the usage of the CTID column change the plan so drastically?

IIRC, type tid doesn't have any hash support.

			regards, tom lane