database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-27 12:41:57 +03:00
Code Activity

Allow merge and hash joins to occur on arbitrary expressions (anything not

Browse Source 
containing a volatile function), rather than only on 'Var = Var' clauses
as before.  This makes it practical to do flatten_join_alias_vars at the
start of planning, which in turn eliminates a bunch of klugery inside the
planner to deal with alias vars.  As a free side effect, we now detect
implied equality of non-Var expressions; for example in
	SELECT ... WHERE a.x = b.y and b.y = 42
we will deduce a.x = 42 and use that as a restriction qual on a.  Also,
we can remove the restriction introduced 12/5/02 to prevent pullup of
subqueries whose targetlists contain sublinks.
Still TODO: make statistical estimation routines in selfuncs.c and costsize.c
smarter about expressions that are more complex than plain Vars.  The need
for this is considerably greater now that we have to be able to estimate
the suitability of merge and hash join techniques on such expressions.
This commit is contained in:
Tom Lane
2003-01-15 19:35:48 +00:00
parent 0eed62f34d
commit de97072e3c
32 changed files with 523 additions and 662 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
doc/src/sgml/xoper.sgml
View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/xoper.sgml,v 1.21 2003/01/06 01:20:40 tgl Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/xoper.sgml,v 1.22 2003/01/15 19:35:35 tgl Exp $
-->
<Chapter Id="xoper">
@ -375,6 +375,27 @@ table1.column1 OP table2.column2
equality operators that are (or could be) implemented by <function>memcmp()</function>.
</para>
<note>
<para>
The function underlying a hashjoinable operator must be marked
immutable or stable. If it is volatile, the system will never
attempt to use the operator for a hash join.
</para>
</note>
<note>
<para>
If a hashjoinable operator has an underlying function that is marked
strict, the
function must also be complete: that is, it should return TRUE or
FALSE, never NULL, for any two non-NULL inputs. If this rule is
not followed, hash-optimization of <literal>IN</> operations may
generate wrong results. (Specifically, <literal>IN</> might return
FALSE where the correct answer per spec would be NULL; or it might
yield an error complaining that it wasn't prepared for a NULL result.)
</para>
</note>
</sect2>
<sect2>
@ -472,6 +493,14 @@ table1.column1 OP table2.column2
</itemizedlist>
</para>
<note>
<para>
The function underlying a mergejoinable operator must be marked
immutable or stable. If it is volatile, the system will never
attempt to use the operator for a merge join.
</para>
</note>
<note>
<para>
<literal>GROUP BY</> and <literal>DISTINCT</> operations require each