On Thu, 30 Oct 2003 [EMAIL PROTECTED] wrote:
> >> So its not just PostgreSQL that is suffering from the bad SQL but MySQL also.
> >> But the
> >> question is my does PostgreSQL suffer so badly ?? I think not all developers
> >> write very nice
> >> SQLs.
> >>
> >> Its really sad to see that a fine peice of work (RT) is performing sub-optimal
> >> becoz of
> >> malformed SQLs. [ specially on database of my choice ;-) ]
> >
> > Post EXPLAIN ANALYZES of the queries you're running, then maybe you'll be able to
> > get some
> > useful help from this list. Until then, it's very hard to speculate as to why
> > PostgreSQL is
> > slower. -sc
>
> Here It is:
>
> in case they are illegeble please lemme know i will attach it as .txt
> files.
>
> Slower One:
>
> explain analyze SELECT DISTINCT main.* FROM Groups main , Principals Principals_1,
> ACL ACL_2
> WHERE ((ACL_2.RightName = 'OwnTicket')OR(ACL_2.RightName = 'SuperUser')) AND ( (
> ACL_2.PrincipalId = Principals_1.id AND ACL_2.PrincipalType = 'Group' AND (
> main.Domain =
> 'SystemInternal' OR main.Domain = 'UserDefined' OR main.Domain = 'ACLEquivalence')
> AND main.id =
> Principals_1.id) OR ( ( (main.Domain = 'RT::Queue-Role' AND main.Instance = 25) OR
> ( main.Domain
> = 'RT::Ticket-Role' AND main.Instance = 6973) ) AND main.Type =
> ACL_2.PrincipalType AND main.id
> = Principals_1.id) ) AND (ACL_2.ObjectType = 'RT::System' OR (ACL_2.ObjectType =
> 'RT::Queue' AND
> ACL_2.ObjectId = 25) ) ORDER BY main.Name ASC ;
Note here:
Merge Join
(cost=1788.68..4735.71 rows=1 width=85)
(actual time=597.540..1340.526 rows=20153 loops=1)
Merge Cond: ("outer".id = "inner".id)
This estimate is WAY off. Are both of those fields indexed and analyzed?
Have you tried upping the statistics target on those two fields?
I assume they are compatible types.
You might try 'set enable_mergejoin = false' and see if it does something
faster here. Just a guess.
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
