To: pgsql-performance@postgresql.org
From: Thomas Kellerer <spam_eater@gmx.net>
Subject: Re: Using ctid column changes plan drastically
Date: Tue, 24 Jul 2012 18:32:09 +0200
Lines: 18
Message-ID: <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>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de;
	rv:1.8.1.21) Gecko/20090302 Thunderbird/2.0.0.21 Mnenhy/0.7.5.666
In-Reply-To: <22819.1343145325@sss.pgh.pa.us>

Tom Lane wrote on 24.07.2012 17:55:
> Joins on tid columns just aren't supported very well at the moment.
> Partly that's from lack of round tuits, and partly it's because it
> doesn't seem all that wise to encourage people to use them.  There
> are gotchas if any of the rows receive concurrent updates.

Thanks for the clarification. I will keep that in mind.

> 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.

Regards
Thomas