From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Rawnsley <ronz(at)ravensfield(dot)com> |
Cc: | Chris <list(at)1006(dot)org>, sferriol <sylvain(dot)ferriol(at)imag(dot)fr>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: faster SELECT |
Date: | 2004-03-08 15:23:39 |
Message-ID: | 3872.1078759419@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Andrew Rawnsley <ronz(at)ravensfield(dot)com> writes:
> It is a fairly well known optimization in Oracle (at least with the
> rule-based optimizer, and IIRC non-indexed clauses) to optimize the
> WHERE clause right to left.
That rule doesn't apply to Postgres, though.
If the optimizer does not have any reasons of its own to reorganize the
query (and that's a pretty big "if") then the WHERE clauses will get
evaluated left-to-right. So if you know which clause is more selective,
write it first.
In practice this really only applies to restriction clauses
(single-relation tests) that are not going to be implemented via an
index scan. Join and index clauses will get sliced, diced, and used
no matter what order you list 'em in.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Wollny | 2004-03-08 17:09:57 | Character Encoding Confusion |
Previous Message | Tom Lane | 2004-03-08 15:06:54 | Re: postmaster freeze |