| From: | Michael Glaesemann <grzm(at)seespotcode(dot)net> |
|---|---|
| To: | Stephen Davies <scldad(at)sdc(dot)com(dot)au> |
| Cc: | Russell Smith <mr-russ(at)pws(dot)com(dot)au>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Optimising "in" queries |
| Date: | 2007-08-23 00:21:05 |
| Message-ID: | D7364220-64D0-4406-A1D6-A5BA4FE67406@seespotcode.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
[Please don't top post as it makes the discussion more difficult to
follow.]
On Aug 22, 2007, at 18:30 , Stephen Davies wrote:
> I have always thought of array processing as the thing that vector
> processors such as Cray and ETA do/did.
(I've always heard that referred to as vector processing.)
> While superficially equivalent, I have always believed that IN (a,b,c)
> executed faster than =a or =b or =c. Am I wrong for PostgreSQL?
Depending on the numbers of the IN list and other statistcs, I
believe PostgreSQL will rewrite z in IN (a, b, ...) into either (z =
a) OR (z = b) OR ... or somehow add it to the join list, so
performance will vary.
Michael Glaesemann
grzm seespotcode net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Russell Smith | 2007-08-23 07:34:01 | Re: Optimising "in" queries |
| Previous Message | Gregory Stark | 2007-08-22 23:50:53 | Re: When/if to Reindex |