* 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
signature.asc
Description: Digital signature