You're right, I should remove that (cruft left over from when the
subselect wasn't). However, it has no impact on the planner at hand:
removing it does trim 25% from the execution time, but getting the
WHERE clauses used in the right order gains an order of magnitude.
Both apply. Thanks, I'll fix
On Wed, Nov 13, 2002 at 08:58:04AM -0500, Tom Lane wrote:
> "Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> > Bingo, that solved it. I'm back to 160 ms. What does Tom feel about
> > removing this? Is there some way the planner could have known which
> > was the smarter/faster order of application
"Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> Bingo, that solved it. I'm back to 160 ms. What does Tom feel about
> removing this? Is there some way the planner could have known which
> was the smarter/faster order of application?
As I said in the previous thread, I don't have a lot of patienc
Am Mittwoch, 13. November 2002 07:22 schrieb Ross J. Reedstrom:
> Hey Hackers -
...
>
> CREATE VIEW current_modules AS
>SELECT * FROM modules m
> WHERE module_ident =
> (SELECT max(module_ident) FROM modules
> WHERE m.moduleid =
On Wed, Nov 13, 2002 at 02:40:40AM -0500, Mike Mascari wrote:
> Ross J. Reedstrom wrote:
> >
> >For this query, the difference is 160 ms vs. 2 sec. Any reason for this
> >change?
>
> I could be way off base, but here's a shot in the dark:
>
>
>http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&o
Ross J. Reedstrom wrote:
Hey Hackers -
I was testing beta5 and found a performance regression involving
application of constraints into a VIEW - I've got a view that is fairly
expensive, involving a subselet and an aggregate. When the query is
rewritten in 7.2.3, the toplevel constraint is used
Hey Hackers -
I was testing beta5 and found a performance regression involving
application of constraints into a VIEW - I've got a view that is fairly
expensive, involving a subselet and an aggregate. When the query is
rewritten in 7.2.3, the toplevel constraint is used to filter before
the subse
