From 0d7437de73b68b0105d00ff4fed3e7894b02f6d5 Mon Sep 17 00:00:00 2001 From: David Rowley Date: Fri, 21 Aug 2020 09:34:47 +1200 Subject: [PATCH] Fix a few typos in JIT comments and README 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 --- src/backend/jit/README | 14 +++++++------- src/include/jit/llvmjit_emit.h | 2 +- 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 *