Thanks to visit codestin.com
Credit goes to postgrespro.com

Re: Multiple Uniques - Mailing list pgsql-performance

From Neil Conway
Subject Re: Multiple Uniques
Date
Msg-id [email protected]
Whole thread Raw
In response to Re: Multiple Uniques  (Tom Lane <[email protected]>)
Responses Re: Multiple Uniques
List pgsql-performance
Tom Lane wrote:
> Markus Schaber <[email protected]> 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

pgsql-performance by date:

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