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
discard
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
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
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;
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;
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) as
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
