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: | Raw Message | Whole Thread | 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 |