Sean,

I wasn't trying to find the best way to update a bunch of records, which
have their counterparts in a second table. The original discussion
concerned a question whether there's a point in trying to refine the
sub-select in EXISTS or the straightforward SELECT * ... is the best
option. The measured times suggest it doesn't matter what set of columns
you select or if you try to reduce the sub-select to a single row - FB
already takes care of that. And I meant only that by writing FB's EXISTS
is efficient. Whether there EXISTS ;) a better way than to use EXISTS at
all - is up to you.

regards
Tomasz

W dniu 2011-10-07 16:43, Leyne, Sean pisze:

> Tomasz,
>
>> Conclusion: using select 1 ... instead of select * ... in the sub-select doesn't
>> improve anything, while using select first(1) ... even slows things down a bit.
>> IMHO, that proves FB handles the sub-selects in an efficient manner, i.e.
>> doesn't retrieve irrelevant data and exits the sub-select as soon as the first
>> record arrives.
>
> Your test has only proved that the EXISTS predicate yields consistent performance regardless of whether SELECT 1 or SELECT * is used.
>
> Your test has NOT proved that FB handles sub-selects in an efficient manner. If you were to use the IN() predicate (as many first time FB users do and some ER frameworks) instead of EXISTS() you would find that a very different story.
>
>
> Sean
>
>

--
__--==============================--__
__--== Tomasz Tyrakowski ==--__
__--== SOL-SYSTEM ==--__
__--== http://www.sol-system.pl ==--__
__--==============================--__