Re: Quick question

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Quick question
Date: 2003-09-09 03:14:29
Message-ID: 19153.1063077269@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Back in the 7.0 days,
> WHERE EXISTS (SELECT * FROM a WHERE condition)
> was significantly slower on broad tables than
> WHERE EXISTS (SELECT small_col FROM a WHERE condition)
> Is this still true, or something that's been fixed in the last 3 versions?

It's still true that all the sub-select's output columns will be
evaluated. Given that this happens for at most one row, I'm not sure
how significant the hit really is. But it's annoying, seeing that the
outer EXISTS doesn't care what the column values are.

> Joe Celko is making fun of me because Oracle doesn't have this performance
> issue.

Perhaps Joe can tell us exactly which part of SQL92 says it's okay not
to evaluate side-effect-producing functions in the targetlist of an
EXISTS subselect.

I would like to make the system change the targetlist to just "SELECT 1"
in an EXISTS subquery. But I'm slightly concerned about changing the
semantics of existing queries. If someone can produce proof that this
is allowed (or even better, required) by the SQL spec, it'd be easier...

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Waruna Geekiyanage 2003-09-09 06:27:27 Slow query?
Previous Message Josh Berkus 2003-09-09 03:02:18 Quick question