Re: Multiple Uniques - Mailing list pgsql-performance

From Tom Lane
Subject Re: Multiple Uniques
Date
Msg-id 13334.1094785631@sss.pgh.pa.us
Whole thread Raw
In response to Re: Multiple Uniques  (Neil Conway <neilc@samurai.com>)
Responses Re: Multiple Uniques
Question on Byte Sizes
List pgsql-performance
Neil Conway <neilc@samurai.com> writes:
> Tom Lane wrote:
>> Because the issue doesn't come up often enough to justify expending
>> cycles to check for it.

> How many cycles are we really talking about, though? I have a patch
> which I'll send along in a few days which implements a similar
> optimization: if a subselect is referenced by EXISTS or IN, we can
> discard DISTINCT and ORDER BY clauses in the subquery

I don't think either of those is worth doing.  ORDER BY in a sub-select
isn't even legal SQL, much less probable, so why should we expend even
a nanosecond to optimize it?  The DISTINCT is more of a judgment call,
but my thought when I looked at it originally is that it would give
people a possible optimization knob.  If you write DISTINCT in an IN
clause then you can get a different plan (the IN reduces to an ordinary
join) that might or might not be better than without it.  We shouldn't
take away that possibility just on the grounds of nanny-ism.

            regards, tom lane

pgsql-performance by date:

Previous
From: Neil Conway
Date:
Subject: Re: Multiple Uniques
Next
From: Tom Lane
Date:
Subject: Re: Costly "Sort Key" on indexed timestamp column