Re: Multiple Uniques

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-09 23:06:23
Message-ID: 4140E1EF.1040303@samurai.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Tom Lane wrote:
> Markus Schaber <schabios(at)logi-track(dot)com> writes:
>>So, now my question is, why does the query optimizer not recognize that
>>it can throw away those "non-unique" Sort/Unique passes?
>
> 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 (actually, we
can't discard ORDER BY in the case of IN if LIMIT is also specified, but
the point remains). It's very cheap computationally for the planner to
do this simplification, and I'd imagine doing the equivalent
simplifications for UNION is similarly cheap.

While I understand what you're saying WRT to it being a silly query, in
the real world people make mistakes...

-Neil

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2004-09-10 03:07:11 Re: Multiple Uniques
Previous Message ogjunk-pgjedan 2004-09-09 22:51:37 Costly "Sort Key" on indexed timestamp column