Tom Lane <[EMAIL PROTECTED]> writes:
> Neil Conway <[EMAIL PROTECTED]> writes:
>
> > 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
>
Neil Conway <[EMAIL PROTECTED]> 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
> opt
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
Hi, Greg,
On 02 Sep 2004 15:33:38 -0400
Greg Stark <[EMAIL PROTECTED]> wrote:
> Markus Schaber <[EMAIL PROTECTED]> writes:
>
> > logigis=# explain select count(id) from (select ref_in_id as id from streets
> > union select nref_in_id as id from streets) as blubb;
> >
Markus Schaber <[EMAIL PROTECTED]> writes:
> logigis=# explain select count(id) from (select ref_in_id as id from streets union
> select nref_in_id as id from streets) as blubb;
>QUERY PLAN
>
> ---
Markus Schaber <[EMAIL PROTECTED]> writes:
> Today, we stumbled about the following query plan on PostGreSQL 7.4.1:
> logigis=# explain select count(id) from (select distinct id from (select distinct
> ref_in_id as id from streets union select distinct nref_in_id as id from streets) as
> blubb)
Hello,
Today, we stumbled about the following query plan on PostGreSQL 7.4.1:
logigis=# explain select count(id) from (select distinct id from (select distinct
ref_in_id as id from streets union select distinct nref_in_id as id from streets) as
blubb) as blabb;
