* Hannu Krosing (hannu@krosing.net) 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
