Fix a few typos in JIT comments and READMEREL_13_STABLE

Reviewed-by: Abhijit Menon-Sen
Reviewed-by: Andres Freund
Discussion: https://postgr.es/m/CAApHDvobgmCs6CohqhKTUf7D8vffoZXQTCBTERo9gbOeZmvLTw%40mail.gmail.com
Backpatch-through: 11, where JIT was added

2 files changed, 8 insertions, 8 deletions

diff --git a/src/backend/jit/README b/src/backend/jit/README
index e2fac8558e..5427bdf215 100644
--- a/src/backend/jit/README
+++ b/src/backend/jit/README
@@ -10,11 +10,11 @@ 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
-where 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 PostgreSQL, the lines between interpretation, AOT and JIT are
-somewhat blurry.
+This is JIT, rather than ahead-of-time (AOT) compilation, because it
+is done at query execution time, and perhaps only in cases where the
+relevant task is repeated a number of times. Given the way JIT
+compilation is used in PostgreSQL, the lines between interpretation,
+AOT and JIT are somewhat blurry.
 
 Note that the interpreted program turned into a native program does
 not necessarily have to be a program in the classical sense. E.g. it
@@ -99,7 +99,7 @@ Lifetimes of JITed functions are managed via JITContext. Exactly one
 such context should be created for work in which all created JITed
 function should have the same lifetime. E.g. there's exactly one
 JITContext for each query executed, in the query's EState.  Only the
-release of an JITContext is exposed to the provider independent
+release of a JITContext is exposed to the provider independent
 facility, as the creation of one is done on-demand by the JIT
 implementations.
 
@@ -231,7 +231,7 @@ needs to be referenced as an offset to one block of memory stored in
 an ExprState, rather than absolute pointers into memory.
 
 Once that is addressed, adding an LRU cache that's keyed by the
-generated LLVM IR will allow to use optimized functions even for
+generated LLVM IR will allow the usage of optimized functions even for
 faster queries.
 
 A longer term project is to move expression compilation to the planner
diff --git a/src/include/jit/llvmjit_emit.h b/src/include/jit/llvmjit_emit.h
index 74607a4377..45b782d8d1 100644
--- a/src/include/jit/llvmjit_emit.h
+++ b/src/include/jit/llvmjit_emit.h
@@ -1,6 +1,6 @@
 /*
  * llvmjit_emit.h
- *	  Helpers to make emitting LLVM IR a it more concise and pgindent proof.
+ *	  Helpers to make emitting LLVM IR a bit more concise and pgindent proof.
  *
  * Copyright (c) 2018-2020, PostgreSQL Global Development Group
  *