Re: Multiple Uniques

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Markus Schaber <schabios(at)logi-track(dot)com>, PostgreSQL Performance List <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Multiple Uniques
Date: 2004-09-10 03:07:11
Message-ID: 13334.1094785631@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Neil Conway <neilc(at)samurai(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2004-09-10 04:17:11 Re: Costly "Sort Key" on indexed timestamp column
Previous Message Neil Conway 2004-09-09 23:06:23 Re: Multiple Uniques