Well Sorry everyone ,
The problem was tracked down to a silly
datatype mismatch between two join columns
in table Groups(instance) and Tickets(id)
(int vs varchar )
7.4b5 is automatically taking care of this
mismatch hence it was getting executed there.
But , The problem is will this behaviour not
allow to go such mistakes unnoticed?
On Friday 31 Oct 2003 4:08 am, Greg Stark wrote:
> Well, you might want to try the EXISTS version. I'm not sure if it'll be
> faster or slower though. In theory it should be the same.
> Hum, I didn't realize the principals table was the largest table. But
> Postgres knew that so one would expect it to have found a better plan. The
> IN/EXISTS handling was recently much improved but perhaps there's still
> room :)
> SELECT *
> FROM tickets
> WHERE EXISTS (
> SELECT 1
> FROM groups
> JOIN principals ON (groups.id = principals.objectid)
> JOIN cachedgroupmembers ON (principals.id =
> cachedgroupmembers.groupid) JOIN users ON (cachedgroupmembers.memberid =
> WHERE lower(users.emailaddress) = '[EMAIL PROTECTED]'
> AND groups.domain = 'RT::Ticket-Role'
> AND groups.type = 'Requestor'
> AND principals.principaltype = 'group'
> AND groups.instance = tickets.id
> AND type = 'ticket'
> AND effectiveid = tickets.id
> AND (status = 'new' OR status = 'open')
> ORDER BY priority DESC
> LIMIT 10;
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]