Hence, the query optimizer could freely convert:
-box '((0,0),(1,1))' >>> MYBOXES.description
+box '((0,0), (1,1))' >>> MYBOXES.description
to
-MYBOXES.description <<< box '((0,0),(1,1))'
+MYBOXES.description <<< box '((0,0), (1,1))'
equal, !==.
The negator link allows the query optimizer to simplify
-NOT MYBOXES.description === box '((0,0),(1,1))'
+NOT MYBOXES.description === box '((0,0), (1,1))'
to
-MYBOXES.description !== box '((0,0),(1,1))'
+MYBOXES.description !== box '((0,0), (1,1))'
The RESTRICT and JOIN options assist the query optimizer in estimating
result sizes. If a clause of the form:
-MYBOXES.description <<< box '((0,0),(1,1))'
+MYBOXES.description <<< box '((0,0), (1,1))'
is present in the qualification,
then
Postgres may have to
CREATE FUNCTION) which accepts arguments of the correct
data types and returns a floating point number. The
query optimizer simply calls this function, passing the
- parameter ((0,0),(1,1)) and multiplies the result by the relation
+ parameter ((0,0), (1,1)) and multiplies the result by the relation
size to get the expected number of instances.
The difference between the function
-my_procedure_1 (MYBOXES.description, box '((0,0),(1,1))')
+my_procedure_1 (MYBOXES.description, box '((0,0), (1,1))')
and the operator
-MYBOXES.description === box '((0,0),(1,1))'
+MYBOXES.description === box '((0,0), (1,1))'
attempts to optimize operators and can