diff --git a/doc/src/sgml/acronyms.sgml b/doc/src/sgml/acronyms.sgml
index 5ad81a4ff77..638ffc9fe83 100644
--- a/doc/src/sgml/acronyms.sgml
+++ b/doc/src/sgml/acronyms.sgml
@@ -373,8 +373,8 @@
     <term><acronym>JIT</acronym></term>
     <listitem>
      <para>
-      <ulink url="https://en.wikipedia.org/wiki/Just-in-time_compilation">Just in Time
-      Compilation</ulink>
+      <ulink url="https://en.wikipedia.org/wiki/Just-in-time_compilation">Just-in-Time
+      compilation</ulink>
      </para>
     </listitem>
    </varlistentry>
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index b45c9bc592f..8025b319597 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -4057,7 +4057,7 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class="
      </varlistentry>
 
 
-     <varlistentry id="guc-jit-above-cost" xreflabel="guc-jit-above-cost">
+     <varlistentry id="guc-jit-above-cost" xreflabel="jit_above_cost">
       <term><varname>jit_above_cost</varname> (<type>floating point</type>)
       <indexterm>
        <primary><varname>jit_above_cost</varname> configuration parameter</primary>
@@ -4065,7 +4065,7 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class="
       </term>
       <listitem>
        <para>
-        Sets the planner's cutoff after which JIT compilation is used as part
+        Sets the planner's cutoff above which JIT compilation is used as part
         of query execution (see <xref linkend="jit"/>). Performing
         <acronym>JIT</acronym> costs time but can accelerate query execution.
 
@@ -4082,7 +4082,7 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class="
       </term>
       <listitem>
        <para>
-        Sets the planner's cutoff after which JIT compiled programs (see <xref
+        Sets the planner's cutoff above which JIT compiled programs (see <xref
         linkend="guc-jit-above-cost"/>) are optimized. Optimization initially
         takes time, but can improve execution speed.  It is not meaningful to
         set this to a lower value than <xref linkend="guc-jit-above-cost"/>.
@@ -4100,7 +4100,7 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class="
       </term>
       <listitem>
        <para>
-        Sets the planner's cutoff after which JIT compiled programs (see <xref
+        Sets the planner's cutoff above which JIT compiled programs (see <xref
         linkend="guc-jit-above-cost"/>) attempt to inline functions and
         operators. Inlining initially takes time, but can improve execution
         speed.  It is unlikely to be beneficial to set
@@ -7419,9 +7419,9 @@ SET XML OPTION { DOCUMENT | CONTENT };
        </para>
        <para>
         If set to a non-existent library <acronym>JIT</acronym> will not
-        available, but no error will be raised. This allows to install JIT
-        support separately from the main <productname>PostgreSQL</productname>
-        package.
+        available, but no error will be raised. This allows JIT support to be
+        installed separately from the main
+        <productname>PostgreSQL</productname> package.
 
         This parameter can only be set at server start.
        </para>
@@ -8702,7 +8702,7 @@ LOG:  CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1)
        <para>
         Writes the generated <productname>LLVM</productname> IR out to the
         filesystem, inside <xref linkend="guc-data-directory"/>. This is only
-        useful for development of JIT.
+        useful for working on the internals of the JIT implementation.
 
         The default setting is <literal>off</literal>, and it can only be
         changed by a superuser.
diff --git a/doc/src/sgml/jit.sgml b/doc/src/sgml/jit.sgml
index be3415fa6ce..7169744d4f9 100644
--- a/doc/src/sgml/jit.sgml
+++ b/doc/src/sgml/jit.sgml
@@ -1,31 +1,31 @@
 <!-- doc/src/sgml/jit.sgml -->
 
 <chapter id="jit">
- <title>Just in Time Compilation (<acronym>JIT</acronym>)</title>
+ <title>Just-in-Time Compilation (<acronym>JIT</acronym>)</title>
 
  <indexterm zone="jit">
   <primary><acronym>JIT</acronym></primary>
  </indexterm>
 
  <indexterm>
-  <primary>Just In Time Compilation</primary>
+  <primary>Just-In-Time compilation</primary>
   <see><acronym>JIT</acronym></see>
  </indexterm>
 
  <para>
-  This chapter explains what Just in Time Compilation is, and how it can be
+  This chapter explains what just-in-time compilation is, and how it can be
   configured in <productname>PostgreSQL</productname>.
  </para>
 
  <sect1 id="jit-reason">
-  <title>What is <acronym>JIT</acronym></title>
+  <title>What is <acronym>JIT</acronym>?</title>
 
   <para>
-   Just in Time Compilation (<acronym>JIT</acronym>) is the process of turning
+   Just-in-time compilation (<acronym>JIT</acronym>) is the process of turning
    some form of interpreted program evaluation into a native program, and
    doing so at runtime.
 
-   E.g. instead of using a facility that can evaluate arbitrary arbitrary SQL
+   For example, instead of using a facility that can evaluate arbitrary SQL
    expressions to evaluate an SQL predicate like <literal>WHERE a.col =
    3</literal>, it is possible to generate a function than can be natively
    executed by the CPU that just handles that expression, yielding a speedup.
@@ -43,7 +43,7 @@
   </para>
 
   <sect2 id="jit-accelerated-operations">
-   <title>JIT accelerated operations</title>
+   <title>JIT Accelerated Operations</title>
    <para>
     Currently <productname>PostgreSQL</productname>'s JIT implementation has
     support for accelerating expression evaluation and tuple deforming.
@@ -52,13 +52,13 @@
    <para>
     Expression evaluation is used to evaluate <literal>WHERE</literal>
     clauses, target lists, aggregates and projections. It can be accelerated
-    by generating code specific to the used expression.
+    by generating code specific to each case.
    </para>
    <para>
     Tuple deforming is the process of transforming an on-disk tuple (see <xref
     linkend="heaptuple"/>) into its in-memory representation. It can be
     accelerated by creating a function specific to the table layout and the
-    number of to be extracted columns.
+    number of columns to be extracted.
    </para>
   </sect2>
 
@@ -67,7 +67,7 @@
    <para>
     <productname>LLVM</productname> has support for optimizing generated
     code. Some of the optimizations are cheap enough to be performed whenever
-    <acronym>JIT</acronym> is used, others are only beneficial for more longer
+    <acronym>JIT</acronym> is used, while others are only beneficial for longer
     running queries.
 
     See <ulink url="https://llvm.org/docs/Passes.html#transform-passes"/> for
@@ -78,14 +78,14 @@
   <sect2 id="jit-inlining">
    <title>Inlining</title>
    <para>
-    <productname>PostgreSQL</productname> is very extensible and allows to
-    extend the set of datatypes, functions, operators, etc.; see <xref
-    linkend="extend"/>. In fact the builtin ones are implemented using nearly
+    <productname>PostgreSQL</productname> is very extensible and allows new
+    datatypes, functions, operators and other database objects to be defined; see <xref
+    linkend="extend"/>. In fact the built-in ones are implemented using nearly
     the same mechanisms.  This extensibility implies some overhead, e.g. due
     to function calls (see <xref linkend="xfunc"/>).  To reduce that overhead
     <acronym>JIT</acronym> compilation can inline the body for small functions
-    into the expression using them. That allows to optimize away a significant
-    percentage of the overhead.
+    into the expression using them. That allows a significant percentage of
+    the overhead to be optimized away.
    </para>
   </sect2>
 
@@ -95,7 +95,7 @@
   <title>When to <acronym>JIT</acronym></title>
 
   <para>
-   <acronym>JIT</acronym> is beneficial primarily for long-running, CPU bound,
+   <acronym>JIT</acronym> is beneficial primarily for long-running CPU bound
    queries. Frequently these will be analytical queries.  For short queries
    the overhead of performing <acronym>JIT</acronym> will often be higher than
    the time it can save.
@@ -117,7 +117,7 @@
    If the planner, based on the above criterion, decided that
    <acronym>JIT</acronym> is beneficial, two further decisions are
    made. Firstly, if the query is more costly than the <xref
-   linkend="guc-jit-optimize-above-cost"/> GUC expensive optimizations are
+   linkend="guc-jit-optimize-above-cost"/>, GUC expensive optimizations are
    used to improve the generated code. Secondly, if the query is more costly
    than the <xref linkend="guc-jit-inline-above-cost"/> GUC, short functions
    and operators used in the query will be inlined.  Both of these operations
@@ -153,7 +153,7 @@
 
   <para>
    As explained in <xref linkend="jit-decision"/> the configuration variables
-   xref <xref linkend="guc-jit-above-cost"/>, <xref
+   <xref linkend="guc-jit-above-cost"/>, <xref
    linkend="guc-jit-optimize-above-cost"/>, <xref
    linkend="guc-jit-inline-above-cost"/> decide whether JIT compilation is
    performed for a query, and how much effort is spent doing so.
@@ -161,8 +161,8 @@
 
   <para>
    For development and debugging purposes a few additional GUCs exist. <xref
-   linkend="guc-jit-dump-bitcode"/> allows to inspect the generated
-   bitcode. <xref linkend="guc-jit-debugging-support"/> allows GDB to see
+   linkend="guc-jit-dump-bitcode"/> allows the generated bitcode to be
+   inspected. <xref linkend="guc-jit-debugging-support"/> allows GDB to see
    generated functions. <xref linkend="guc-jit-profiling-support"/> emits
    information so the <productname>perf</productname> profiler can interpret
    JIT generated functions sensibly.
@@ -179,7 +179,7 @@
   <title>Extensibility</title>
 
   <sect2 id="jit-extensibility-bitcode">
-   <title>Inlining support for extensions</title>
+   <title>Inlining Support for Extensions</title>
    <para>
     <productname>PostgreSQL</productname>'s <acronym>JIT</acronym>
     implementation can inline the implementation of operators and functions
@@ -231,7 +231,7 @@
      <function>_PG_jit_provider_init</function>. This function is
      passed a struct that needs to be filled with the callback function
      pointers for individual actions.
-	 <programlisting>
+     <programlisting>
 struct JitProviderCallbacks
 {
     JitProviderResetAfterErrorCB reset_after_error;
@@ -239,7 +239,7 @@ struct JitProviderCallbacks
     JitProviderCompileExprCB compile_expr;
 };
 extern void _PG_jit_provider_init(JitProviderCallbacks *cb);
-	 </programlisting>
+     </programlisting>
     </para>
    </sect3>
   </sect2>
diff --git a/src/backend/jit/README b/src/backend/jit/README
index 03ec3253ee5..b37dcbe0c16 100644
--- a/src/backend/jit/README
+++ b/src/backend/jit/README
@@ -1,18 +1,18 @@
-What is Just in Time Compilation
-================================
+What is Just-in-Time Compilation?
+=================================
 
-Just in Time Compilation (JIT) is the process of turning some form of
+Just-in-Time compilation (JIT) is the process of turning some form of
 interpreted program evaluation into a native program, and doing so at
 runtime.
 
-E.g. instead of using a facility that can evaluate arbitrary arbitrary
+For example, instead of using a facility that can evaluate arbitrary
 SQL expressions to evaluate an SQL predicate like WHERE a.col = 3, it
 is possible to generate a function than can be natively executed by
 the CPU that just handles that expression, yielding a speedup.
 
 That this is done at query execution time, possibly even only in cases
 the relevant task is done a number of times, makes it JIT, rather than
-ahead of time (AOT). Given the way JIT compilation is used in
+ahead-of-time (AOT). Given the way JIT compilation is used in
 postgres, the lines between interpretation, AOT and JIT are somewhat
 blurry.
 
@@ -23,8 +23,8 @@ function just handling a specific type of table, despite tuple
 deforming not commonly being understood as a "program".
 
 
-Why JIT
-=======
+Why JIT?
+========
 
 Parts of postgres are commonly bottlenecked by comparatively small
 pieces of CPU intensive code. In a number of cases that is because the
@@ -52,11 +52,11 @@ How to JIT
 Postgres, by default, uses LLVM to perform JIT. LLVM was chosen
 because it is developed by several large corporations and therefore
 unlikely to be discontinued, because it has a license compatible with
-PostgreSQL, and because it's LLVM IR allow can be generated from C
+PostgreSQL, and because its LLVM IR can be generated from C
 using the clang compiler.
 
 
-Shared Library separation
+Shared Library Separation
 -------------------------
 
 To avoid the main PostgreSQL binary directly depending on LLVM, which
@@ -127,7 +127,7 @@ used.
 Error Handling
 --------------
 
-There's two aspects to error handling.  Firstly, generated (LLVM IR)
+There are two aspects to error handling.  Firstly, generated (LLVM IR)
 and emitted functions (mmap()ed segments) need to be cleaned up both
 after a successful query execution and after an error. This is done by
 registering each created JITContext with the current resource owner,
@@ -138,7 +138,7 @@ The second, less pretty, aspect of error handling is OOM handling
 inside LLVM itself. The above resowner based mechanism takes care of
 cleaning up emitted code upon ERROR, but there's also the chance that
 LLVM itself runs out of memory. LLVM by default does *not* use any C++
-exceptions. It's allocations are primarily funneled through the
+exceptions. Its allocations are primarily funneled through the
 standard "new" handlers, and some direct use of malloc() and
 mmap(). For the former a 'new handler' exists
 http://en.cppreference.com/w/cpp/memory/new/set_new_handler for the
@@ -193,14 +193,14 @@ Inlining
 --------
 
 One big advantage of JITing expressions is that it can significantly
-reduce the overhead of postgres' extensible function/operator
+reduce the overhead of postgres's extensible function/operator
 mechanism, by inlining the body of called functions / operators.
 
 It obviously is undesirable to maintain a second implementation of
 commonly used functions, just for inlining purposes. Instead we take
 advantage of the fact that the clang compiler can emit LLVM IR.
 
-The ability to do so allows to get the LLVM IR for all operators
+The ability to do so allows us to get the LLVM IR for all operators
 (e.g. int8eq, float8pl etc), without maintaining two copies.  These
 bitcode files get installed into the server's
   $pkglibdir/bitcode/postgres/
@@ -260,7 +260,7 @@ generation, and later compiling larger parts of queries.
 When to JIT
 ===========
 
-Currently there's a number of GUCs that influence JITing:
+Currently there are a number of GUCs that influence JITing:
 
 - jit_above_cost = -1, 0-DBL_MAX - all queries with a higher total cost
   get JITed, *without* optimization (expensive part), corresponding to