Tom Lane <[EMAIL PROTECTED]> writes:
> Are you sure this WHERE clause really expresses your intent? It seems
> awfully oddly constructed. Removing the redundant parens and clarifying
> the layout, I get
...
> That next-to-last major AND clause seems a rather unholy mix of join and
> restriction
On Feb 9, 2006, at 6:36 PM, Rafael Martinez wrote:
This is an application that we have not programmed, so I am not sure
what they are trying to do here. I will contact the developers.
Tomorrow
I will try to test some of your suggestions.
well, obviously you're running RT... what you want t
On Thu, 2006-02-09 at 18:22 -0500, Tom Lane wrote:
> Rafael Martinez Guerrero <[EMAIL PROTECTED]> writes:
> > WHERE ((ACL_2.RightName = 'OwnTicket'))
> > AND ((CachedGroupMembers_4.MemberId = Principals_1.id))
> > AND ((Groups_3.id = CachedGroupMembers_4.GroupId))
> > AND ((Principals_1.Disabled
Rafael Martinez Guerrero <[EMAIL PROTECTED]> writes:
> WHERE ((ACL_2.RightName = 'OwnTicket'))
> AND ((CachedGroupMembers_4.MemberId = Principals_1.id))
> AND ((Groups_3.id = CachedGroupMembers_4.GroupId))
> AND ((Principals_1.Disabled = '0') or (Principals_1.Disabled = '0'))
> AND ((Principals
On Thu, 2006-02-09 at 13:46 -0600, Jim C. Nasby wrote:
> I looked at the estimates for the table access methods and they all
> looked ok, so I think the statistics are pretty up-to-date; there just
> aren't enough of them for the planner to do a good job.
>
VACUUM ANALYZE runs 4 times every hour,
Thursday, February 09, 2006 1:34 PM
> To: Rafael Martinez Guerrero
> Cc: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Help with optimizing a sql statement
>
> At least part of the problem is that it's way off on some of the row
> estimates. I'd suggest uppin
ruary 09, 2006 1:34 PM
To: Rafael Martinez Guerrero
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Help with optimizing a sql statement
At least part of the problem is that it's way off on some of the row
estimates. I'd suggest upping the statisticss target on at least all of
t
At least part of the problem is that it's way off on some of the row
estimates. I'd suggest upping the statisticss target on at least all of
the join columns to at least 100. (Note that it's doing a nested loop
thinking it will have only 2 rows but it actually has 22000 rows).
On Thu, Feb 09, 2006
Hello
We are running an application via web that use a lot of time to perform
some operations. We are trying to find out if some of the sql statements
used are the reason of the slow speed.
We have identified a sql that takes like 4-5000ms more than the second
slowest sql in out test server. I ho
