Re: Using ctid column changes plan drastically - Mailing list pgsql-performance

From Thomas Kellerer
Subject Re: Using ctid column changes plan drastically
Date
Msg-id jumcuv$26n$1@dough.gmane.org
Whole thread Raw
In response to Re: Using ctid column changes plan drastically  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Using ctid column changes plan drastically  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
Tom Lane, 24.07.2012 16:23:
> 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?

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



pgsql-performance by date:

Previous
From: Ioannis Anagnostopoulos
Date:
Subject: Re: Heavy inserts load wile querying...
Next
From: Maciek Sakrejda
Date:
Subject: Re: Geoserver-PostGIS performance problems