Thank you guys.
I had no idea that indices will not work when comparing two different data
types. But now when I am thinking about it, it makes sense:)
Thanks!
Actually any integer type is faster than any string type. Using the
native integer type may be best, but not much of one as there are
assembler instructions for each and every integer type.
For those wondering - computers are best with numbers - they compare two
of them with one assembler instruct
Ray Holme schrieb am 30.04.2012 um 19:15 (-0400):
> If you want performance too, make as many of your join criteria
> numerical and of the same type. I try to search on strings but join
> tables on integers (or bigints or shorts, doubles and floats are OK
> but not as good)
Yes. I once was given t
If you want performance too, make as many of your join criteria
numerical and of the same type. I try to search on strings but join
tables on integers (or bigints or shorts, doubles and floats are OK but
not as good)
You can also play with the play and tell the optimizer a better one.
On Mon, 201
--- In firebird-support@yahoogroups.com, "jankowalsky825" wrote:
>
> Hi guys.
>
> I've read whatever I could find about this problem. Suggestion is to create a
> proper indices and that should speed up the query but query optimizer do not
> take my indices into account and generates natural pl
