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: <jumim1$nq7$1@dough.gmane.org>
References: <julsfr$otg$1@dough.gmane.org> <21308.1343139781@sss.pgh.pa.us>
	<jumcuv$26n$1@dough.gmane.org> <22819.1343145325@sss.pgh.pa.us>
	<jumim1$nq7$1@dough.gmane.org>
Comments: In-reply-to Thomas Kellerer <spam_eater@gmx.net>
	message dated "Tue, 24 Jul 2012 18:32:09 +0200"
Date: Tue, 24 Jul 2012 13:12:46 -0400
Message-ID: <24101.1343149966@sss.pgh.pa.us>

Thomas Kellerer <spam_eater@gmx.net> writes:
> Tom Lane wrote on 24.07.2012 17:55:
>> FWIW, it might be helpful to cast this as a NOT EXISTS rather than
>> NOT IN subquery.

> Hmm. How would you change that into an NOT EXISTS clause (so that one of the duplicates remains)
> Everything I come up with is in fact slower than the NOT IN solution.

Well, it would only help if you're running a PG version that's new
enough to recognize the NOT EXISTS as an anti-join; and even then,
it's possible that joining on a tid column forecloses enough plan
types that you don't get any real benefit.  But I'm just guessing.
Can you show exactly what you tried and what EXPLAIN ANALYZE results
you got?

			regards, tom lane