* Hannu Krosing (ha...@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

Attachment: signature.asc
Description: Digital signature

Reply via email to