@@ -1083,10 +1083,10 @@ SELECT x, g FROM tab, LATERAL generate_series(1,5) AS g;
1083
1083
</programlisting>
1084
1084
It would be exactly the same, except that in this specific example,
1085
1085
the planner could choose to put <structname>g</structname> on the outside of the
1086
- nestloop join, since <structname>g</structname> has no actual lateral dependency
1086
+ nested-loop join, since <structname>g</structname> has no actual lateral dependency
1087
1087
on <structname>tab</structname>. That would result in a different output row
1088
1088
order. Set-returning functions in the select list are always evaluated
1089
- as though they are on the inside of a nestloop join with the rest of
1089
+ as though they are on the inside of a nested-loop join with the rest of
1090
1090
the <literal>FROM</literal> clause, so that the function(s) are run to
1091
1091
completion before the next row from the <literal>FROM</literal> clause is
1092
1092
considered.
@@ -3441,14 +3441,14 @@ supportfn(internal) returns internal
3441
3441
</para>
3442
3442
3443
3443
<para>
3444
- For target functions that return boolean, it is often useful to estimate
3445
- the fraction of rows that will be selected by a WHERE clause using that
3444
+ For target functions that return <type> boolean</type> , it is often useful to estimate
3445
+ the fraction of rows that will be selected by a <literal> WHERE</literal> clause using that
3446
3446
function. This can be done by a support function that implements
3447
3447
the <literal>SupportRequestSelectivity</literal> request type.
3448
3448
</para>
3449
3449
3450
3450
<para>
3451
- If the target function's runtime is highly dependent on its inputs,
3451
+ If the target function's run time is highly dependent on its inputs,
3452
3452
it may be useful to provide a non-constant cost estimate for it.
3453
3453
This can be done by a support function that implements
3454
3454
the <literal>SupportRequestCost</literal> request type.
@@ -3462,15 +3462,15 @@ supportfn(internal) returns internal
3462
3462
</para>
3463
3463
3464
3464
<para>
3465
- For target functions that return boolean, it may be possible to
3466
- convert a function call appearing in WHERE into an indexable operator
3465
+ For target functions that return <type> boolean</type> , it may be possible to
3466
+ convert a function call appearing in <literal> WHERE</literal> into an indexable operator
3467
3467
clause or clauses. The converted clauses might be exactly equivalent
3468
3468
to the function's condition, or they could be somewhat weaker (that is,
3469
3469
they might accept some values that the function condition does not).
3470
3470
In the latter case the index condition is said to
3471
3471
be <firstterm>lossy</firstterm>; it can still be used to scan an index,
3472
3472
but the function call will have to be executed for each row returned by
3473
- the index to see if it really passes the WHERE condition or not.
3473
+ the index to see if it really passes the <literal> WHERE</literal> condition or not.
3474
3474
To create such conditions, the support function must implement
3475
3475
the <literal>SupportRequestIndexCondition</literal> request type.
3476
3476
</para>
0 commit comments