the optimizer and exists

From: "Thomas F(dot) O'Connell" <tfo(at)monsterlabs(dot)com>
To: pgsql-hackers(at)postgresql(dot)org, pgsql-sql(at)postgresql(dot)org
Subject: the optimizer and exists
Date: 2002-08-29 16:13:03
Message-ID: aklh69$2qt$1@news.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-sql

i think i might've stumbled across a tiny defect in the optimizer.
unfortunately, i haven't the knowledge of the code to know where to
begin looking at how to address this problem.

anyway, consider the following:

create table foo(
id int2
);

create table bar(
id int2
foo_id int2 references foo( id )
);

imagine that the tables are populated.

now, consider the query

select b.foo_id
from bar b
where b.id = <some id>
and
exists(
select *
from foo f
where b.foo_id = f.id
and b.id = <some id, as above>
);

now consider the same query with "select <constant>" in place of "select
*" in the EXISTS subquery.

explain analyze indicates that the constant version always runs a little
bit faster. shouldn't the optimizer be able to determine that it isn't
necessary actually to read a row in the case of EXISTS? i'm assuming
that's where the overhead is coming into play.

i realize this is minutiae in comparison to other aspects of
development, but it is another small performance boost that could be
added since i imagine many people, myself included, find it more natural
to throw in "select *" rather than "select <constant>".

i didn't see this on the current lists or TODO, but if it's a dupe, i
apologize for the noise. i also apologize for not being able to patch
it, myself!

-tfo

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-08-29 16:14:24 Re: [HACKERS] Proposed GUC Variable
Previous Message Robert Treat 2002-08-29 16:09:58 Re: [HACKERS] Proposed GUC Variable

Browse pgsql-sql by date

  From Date Subject
Next Message Josh Berkus 2002-08-29 17:52:39 Re: union optimization in views
Previous Message Greg Patnude 2002-08-29 15:35:42 Why must the function that a trigger calls return "opaque" ???