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 ==--__ __--==============================--__
