* Hannu Krosing ([email protected]) wrote: > The main exposed implementation detail of this operator is that it is > very fast and can be recommended to be used at user level for speeding > up equal query like this > > SELECT * FROM t WHERE <guaranteed equal> or <equal> > > where the plain <equal> will only be called when fast <guaranteed equal> > fails.
Yeah, this would be exactly the kind of misuse that we will need to be
prepared to support with these new operators. If this is actually
faster/better/whatever, then we should be implementing it in our
conditional handling, not encouraging users to create hacks like this.
> a bit similar to how you can cut down on index size on long text fields by
> indexing their hashes and then querying
>
> SELECT * FROM t
> WHERE hashtext(verylongtext) = hashtext(sample)
> AND verylongtext = sample
This case clearly requires a great deal more thought and consideration
on the DBA's side and is also a lot more obvious what it's doing than
having 'where x *= 123 or x = 123'.
Thanks,
Stephen
signature.asc
Description: Digital signature
