> I have now managed to get a plan for the initial query. Here it

goes:

>
> PLAN JOIN (UNIFIEDMES_2 INDEX (RDB$PRIMARY339),DESIGNITEM_1 INDEX
> (RDB$PRIMARY326),SENDABLEDE_1 INDEX (RDB$PRIMARY372),DESIGN_1 INDEX
> (RDB$PRIMARY325))
>
> PLAN JOIN (CUSTOMER_1 INDEX (RDB$PRIMARY323),ENTITY_1 INDEX
> (IX_ENTITY_CUSTOMER),UNIFIEDMES_1 INDEX
> (IX_UNIFIEDMESSAGE_BOLD_TYPE,IX_UNIFIEDMESSAGE_ENTITY),GALAXYOBJE_1
> INDEX (RDB$PRIMARY320))
>
> I have removed the Created-index.
>
> This is the sql-89 only version:
>
> SELECT UnifiedMes_1.ID, UnifiedMes_1.TYPE
> FROM Customer Customer_1, Entity Entity_1,
> UnifiedMessage UnifiedMes_1, GalaxyObject GalaxyObje_1
> WHERE Entity_1.Customer = Customer_1.ID AND
> UnifiedMes_1.Entity = Entity_1.ID AND
> UnifiedMes_1.ID = GalaxyObje_1.ID AND
> (Customer_1.ID = 37308) AND
> (UnifiedMes_1.TYPE IN (37)) AND
> (((GalaxyObje_1.Created > '06/01/2003') and
> (GalaxyObje_1.Created < '06/01/2004')) and
> EXISTS (SELECT Design_1.ID FROM
> SendableDesignItem SendableDe_1,
> UnifiedMessage UnifiedMes_2,
> Design Design_1, DesignItem DesignItem_1
> WHERE UnifiedMes_1.ID = UnifiedMes_2.ID AND
> SendableDe_1.ID = UnifiedMes_2.SendableDesignItem AND
> SendableDe_1.ID = DesignItem_1.ID AND
> Design_1.ID = DesignItem_1.OwningDesign AND
> (Design_1.Kind = 0)))

I think I've seen this type of thing before one one or two of my own
queries with FB. Try this and check to see if it makes any
difference: For testing purposes remove the select from the exists
clause and replace it with a simple static data set and see if it
speeds the main select up.

I have a feeling that for every record your main select is trying to
generate your exists select get fired. If the data from the exists
select never changes but it returns alot of records that could be your
problem.

You may need to tweak your exists select?

Ryan.