| From: | Phil Endecott <spam_from_postgresql_general(at)chezphil(dot)org> |
|---|---|
| To: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Propogating conditions into a query |
| Date: | 2005-06-09 17:07:51 |
| Message-ID: | 42A87767.3070103@chezphil.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Tom Lane wrote:
> Phil Endecott <spam_from_postgresql_general(at)chezphil(dot)org> writes:
>
>>I have a number of complex views for which the typical use is to select
>>exactly one row by id, e.g. "select * from V where id=nnn". Some of
>>these selects run orders of magnitude faster than others. Looking at
>>the output of "explain analyse" it seems that in the fast cases the
>>"id=nnn" condition is passed down to the lower-level operations, while
>>in the slower cases the entire view is created and then filtered using
>>the condition as a final step.
>
> When in doubt, use the source ;-) ... most sorts of things like this are
> pretty well commented, if you can find the relevant code.
Good plan.
> * 3. If the subquery uses DISTINCT ON, we must not push down any quals that
> * refer to non-DISTINCT output columns, because that could change the set
> * of rows returned.
OK, so this is why my query with DISTINCT ON was failing. I can fix that.
I don't see anything in there about LEFT OUTER JOIN though. Any ideas?
--Phil.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-06-09 17:17:16 | Re: Propogating conditions into a query |
| Previous Message | Ron Snyder | 2005-06-09 17:06:10 | Re: postgreSQL 7.3.8, pg_dump not able to find large o |