Skip to content

P
Postgres FD Implementation
Commit 7eb16b78 authored by Thomas G. Lockhart's avatar Thomas G. Lockhart
Browse files
Options

Add section from Tom Lane on hashjoin characteristics of operators. 

Add emacs editor hints to bottom of file.
parent fb5460bf
Hide whitespace changes
Inline Side-by-side
Showing with 115 additions and 51 deletions
doc/src/sgml/xoper.sgml
View file @ 7eb16b78
<Chapter Id="xoper"> <Chapter Id="xoper">
<Title>Extending <Acronym>SQL</Acronym>: Operators</Title> <Title>Extending <Acronym>SQL</Acronym>: Operators</Title>
<Para> <Para>
<ProductName>Postgres</ProductName> supports left unary, right unary and binary <ProductName>Postgres</ProductName> supports left unary,
operators. Operators can be overloaded, or re-used right unary and binary
with different numbers and types of arguments. If operators. Operators can be overloaded, or re-used
there is an ambiguous situation and the system cannot with different numbers and types of arguments. If
determine the correct operator to use, it will return there is an ambiguous situation and the system cannot
an error and you may have to typecast the left and/or determine the correct operator to use, it will return
right operands to help it understand which operator you an error and you may have to typecast the left and/or
meant to use. right operands to help it understand which operator you
To create an operator for adding two complex numbers meant to use.
can be done as follows. First we need to create a To create an operator for adding two complex numbers
function to add the new types. Then, we can create the can be done as follows. First we need to create a
operator with the function. function to add the new types. Then, we can create the
operator with the function.
<ProgramListing>
CREATE FUNCTION complex_add(complex, complex) <ProgramListing>
RETURNS complex CREATE FUNCTION complex_add(complex, complex)
AS '$PWD/obj/complex.so' RETURNS complex
LANGUAGE 'c'; AS '$PWD/obj/complex.so'
LANGUAGE 'c';
CREATE OPERATOR + (
leftarg = complex, CREATE OPERATOR + (
rightarg = complex, leftarg = complex,
procedure = complex_add, rightarg = complex,
commutator = + procedure = complex_add,
); commutator = +
</ProgramListing> );
</Para> </ProgramListing>
</Para>
<Para>
We've shown how to create a binary operator here. To <Para>
create unary operators, just omit one of leftarg (for We've shown how to create a binary operator here. To
left unary) or rightarg (for right unary). create unary operators, just omit one of leftarg (for
If we give the system enough type information, it can left unary) or rightarg (for right unary).
automatically figure out which operators to use. If we give the system enough type information, it can
automatically figure out which operators to use.
<ProgramListing> <ProgramListing>
SELECT (a + b) AS c FROM test_complex; SELECT (a + b) AS c FROM test_complex;
+----------------+ +----------------+
|c | |c |
+----------------+ +----------------+
|(5.2,6.05) | |(5.2,6.05) |
+----------------+ +----------------+
|(133.42,144.95) | |(133.42,144.95) |
+----------------+ +----------------+
</ProgramListing> </ProgramListing>
</Para> </Para>
</Chapter>
<sect1>
<title>Hash Join Operators</title>
<note>
<title>Author</title>
<para>
Written by Tom Lane.
</para>
</note>
<para>
The assumption underlying hash join is that two values that will be
considered equal by the comparison operator will always have the same
hash value. If two values get put in different hash buckets, the join
will never compare them at all, so they are necessarily treated as
unequal.
</para>
<para>
But we have a number of datatypes for which the "=" operator is not
a straight bitwise comparison. For example, intervaleq is not bitwise
at all; it considers two time intervals equal if they have the same
duration, whether or not their endpoints are identical. What this means
is that a join using "=" between interval fields will yield different
results if implemented as a hash join than if implemented another way,
because a large fraction of the pairs that should match will hash to
different values and will never be compared.
</para>
<para>
I believe the same problem exists for float data; for example, on
IEEE-compliant machines, minus zero and plus zero have different bit
patterns (hence different hash values) but should be considered equal.
A hashjoin will get it wrong.
</para>
<para>
I will go through pg_operator and remove the hashable flag from
operators that are not safely hashable, but I see no way to
automatically check for this sort of mistake. The only long-term
answer is to raise the consciousness of datatype creators about what
it means to set the oprcanhash flag. Don't do it unless your equality
operator can be implemented as memcmp()!
</para>
</sect1>
</Chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:nil
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document:nil
sgml-default-dtd-file:"./reference.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:"/usr/lib/sgml/CATALOG"
sgml-local-ecat-files:nil
End:
-->
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment