Update admin guide and ref guide functions docs for replicated tables
* Update admin guide and ref guide functions docs for replicated tables
Functions that execute on segments can perform read-only queries on replicated tables.
Add an example function that queries a replicated table on segments.
* Rewrite a difficult sentence.
<body>
<ul>
<li id="in140953">
- <xref format="dita" href="#topic27" type="topic"/>
- </li>
+ <xref format="dita" href="#topic27" type="topic"/></li>
<li id="in141620">
<xref format="dita" href="#topic28" type="topic"/>
</li>
ON</codeph> indicates where it is executed. The volatility attributes are
PostgreSQL based attributes, the <codeph>EXECUTE ON</codeph> attributes are
Greenplum Database attributes.</p>
- <p>For example, a function defined with the <codeph>IMMUTABLE</codeph> attribute can be
- executed at query planning time, while a function with the <codeph>VOLATILE</codeph>
- attribute must be executed for every row in the query. A function with the
- <codeph>EXECUTE ON MASTER</codeph> attribute executes only on the master
- segment, and a function with the <codeph>EXECUTE ON ALL SEGMENTS</codeph> attribute
- executes on all primary segment instances (not the master). </p>
+ <p>For example, a function defined with the <codeph>IMMUTABLE</codeph> attribute can be executed at query
+ planning time, while a function with the <codeph>VOLATILE</codeph> attribute must be executed for every
+ row in the query. A function with the <codeph>EXECUTE ON MASTER</codeph> attribute executes only on the
+ master instance, and a function with the <codeph>EXECUTE ON ALL SEGMENTS</codeph> attribute executes on
+ all primary segment instances (not the master). </p>
<p>These tables summarize what Greenplum Database assumes about function execution based
on the attribute.</p>
<table id="in201681">
such as <codeph>setval()</codeph> are not allowed to execute on distributed data in
Greenplum Database because they can cause inconsistent data between segment
instances.</p>
+ <p>A function can execute read-only queries on replicated tables (<codeph>DISTRIBUTED REPLICATED</codeph>)
+ on the segments, but any SQL command that modifies data must execute on the master instance. </p>
<p>To ensure data consistency, you can safely use <codeph>VOLATILE</codeph> and
<codeph>STABLE</codeph> functions in statements that are evaluated on and run
from the master. For example, the following statements run on the master (statements
@@ -194,13 +194,14 @@ SELECT foo();</codeblock>
default, user-defined functions are declared as <codeph>VOLATILE</codeph>, so if
your user-defined function is <codeph>IMMUTABLE</codeph> or <codeph>STABLE</codeph>,
you must specify the correct volatility level when you register your function.</p>
- <p>By default, user-defined functions are declared as <codeph>EXEUCTE ON ANY</codeph>. A
- function that executes queries to access tables is supported only when a function
- executes on the master instance. Such functions must be defined with the
- <codeph>EXECUTE ON MASTER</codeph> attribute. Otherwise, the function might
- return incorrect results when the function is used in a complicated query. Without
- the attribute, planner optimization might determine it would be beneficial to push
- the function invocation to segment instances. </p>
+ <p>By default, user-defined functions are declared as <codeph>EXECUTE ON ANY</codeph>. A function that
+ executes queries to access tables is supported only when the function executes on the master instance,
+ except that a function can execute <codeph>SELECT</codeph> commands that access only replicated tables
+ on the segment instances. A function that accesses hash-distributed or randomly distributed tables must
+ be defined with the <codeph>EXECUTE ON MASTER</codeph> attribute. Otherwise, the function might return
+ incorrect results when the function is used in a complicated query. Without the attribute, planner
+ optimization might determine it would be beneficial to push the function invocation to segment
+ instances. </p>
<p>When you create user-defined functions, avoid using fatal errors or destructive
calls. Greenplum Database may respond to such errors with a sudden shutdown or
restart.</p>
