agora inbox for [email protected]help / color / mirror / Atom feed
[PATCH v1] generate JIT IR code lazily 17+ messages / 2 participants [nested] [flat]
* [PATCH v1] generate JIT IR code lazily @ 2020-12-28 08:01 Luc Vlaming <[email protected]> 0 siblings, 0 replies; 17+ messages in thread From: Luc Vlaming @ 2020-12-28 08:01 UTC (permalink / raw) --- src/backend/jit/llvm/llvmjit_expr.c | 98 +++++++++++++++++------------ 1 file changed, 59 insertions(+), 39 deletions(-) diff --git a/src/backend/jit/llvm/llvmjit_expr.c b/src/backend/jit/llvm/llvmjit_expr.c index 3aa08a9743..2ac79b7571 100644 --- a/src/backend/jit/llvm/llvmjit_expr.c +++ b/src/backend/jit/llvm/llvmjit_expr.c @@ -52,6 +52,7 @@ typedef struct CompiledExprState } CompiledExprState; +static Datum ExecCompileExpr(ExprState *state, ExprContext *econtext, bool *isNull); static Datum ExecRunCompiledExpr(ExprState *state, ExprContext *econtext, bool *isNull); static LLVMValueRef BuildV1Call(LLVMJitContext *context, LLVMBuilderRef b, @@ -70,18 +71,66 @@ static LLVMValueRef create_LifetimeEnd(LLVMModuleRef mod); lengthof(((LLVMValueRef[]){__VA_ARGS__})), \ ((LLVMValueRef[]){__VA_ARGS__})) - /* - * JIT compile expression. + * Prepare the JIT compile expression. */ bool llvm_compile_expr(ExprState *state) { PlanState *parent = state->parent; - char *funcname; - LLVMJitContext *context = NULL; + + /* + * Right now we don't support compiling expressions without a parent, as + * we need access to the EState. + */ + Assert(parent); + + llvm_enter_fatal_on_oom(); + + /* get or create JIT context */ + if (parent->state->es_jit) + context = (LLVMJitContext *) parent->state->es_jit; + else + { + context = llvm_create_context(parent->state->es_jit_flags); + parent->state->es_jit = &context->base; + } + + /* + * Don't immediately emit nor actually generate the function. + * instead do so the first time the expression is actually evaluated. + * That allows to emit a lot of functions together, avoiding a lot of + * repeated llvm and memory remapping overhead. It also helps with not + * compiling functions that will never be evaluated, as can be the case + * if e.g. a parallel append node is distributing workers between its + * child nodes. + */ + { + + CompiledExprState *cstate = palloc0(sizeof(CompiledExprState)); + + cstate->context = context; + + state->evalfunc = ExecCompileExpr; + state->evalfunc_private = cstate; + } + + llvm_leave_fatal_on_oom(); + + return true; +} + +/* + * JIT compile expression. + */ +static Datum +ExecCompileExpr(ExprState *state, ExprContext *econtext, bool *isNull) +{ + CompiledExprState *cstate = state->evalfunc_private; + LLVMJitContext *context = cstate->context; + LLVMBuilderRef b; LLVMModuleRef mod; LLVMValueRef eval_fn; @@ -125,31 +174,16 @@ llvm_compile_expr(ExprState *state) llvm_enter_fatal_on_oom(); - /* - * Right now we don't support compiling expressions without a parent, as - * we need access to the EState. - */ - Assert(parent); - - /* get or create JIT context */ - if (parent->state->es_jit) - context = (LLVMJitContext *) parent->state->es_jit; - else - { - context = llvm_create_context(parent->state->es_jit_flags); - parent->state->es_jit = &context->base; - } - INSTR_TIME_SET_CURRENT(starttime); mod = llvm_mutable_module(context); b = LLVMCreateBuilder(); - funcname = llvm_expand_funcname(context, "evalexpr"); + cstate->funcname = llvm_expand_funcname(context, "evalexpr"); /* create function */ - eval_fn = LLVMAddFunction(mod, funcname, + eval_fn = LLVMAddFunction(mod, cstate->funcname, llvm_pg_var_func_type("TypeExprStateEvalFunc")); LLVMSetLinkage(eval_fn, LLVMExternalLinkage); LLVMSetVisibility(eval_fn, LLVMDefaultVisibility); @@ -2350,30 +2384,16 @@ llvm_compile_expr(ExprState *state) LLVMDisposeBuilder(b); - /* - * Don't immediately emit function, instead do so the first time the - * expression is actually evaluated. That allows to emit a lot of - * functions together, avoiding a lot of repeated llvm and memory - * remapping overhead. - */ - { - - CompiledExprState *cstate = palloc0(sizeof(CompiledExprState)); - - cstate->context = context; - cstate->funcname = funcname; - - state->evalfunc = ExecRunCompiledExpr; - state->evalfunc_private = cstate; - } - llvm_leave_fatal_on_oom(); INSTR_TIME_SET_CURRENT(endtime); INSTR_TIME_ACCUM_DIFF(context->base.instr.generation_counter, endtime, starttime); - return true; + /* remove indirection via this function for future calls */ + state->evalfunc = ExecRunCompiledExpr; + + return ExecRunCompiledExpr(state, econtext, isNull); } /* -- 2.25.1 --------------896D2E247913574437C36E84-- ^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH v2.7 33/35] Temporary: Increase BAS_BULKREAD size @ 2024-09-01 04:42 Andres Freund <[email protected]> 0 siblings, 0 replies; 17+ messages in thread From: Andres Freund @ 2024-09-01 04:42 UTC (permalink / raw) Without this we only can execute very little AIO for sequential scans, as there's just not enough buffers in the ring. This isn't the right fix, as just increasing the ring size can have negative performance implications in workloads where the kernel has all the data cached. Author: Reviewed-By: Discussion: https://postgr.es/m/ Backpatch: --- src/backend/storage/buffer/freelist.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/backend/storage/buffer/freelist.c b/src/backend/storage/buffer/freelist.c index 336715b6c63..b72a5957a20 100644 --- a/src/backend/storage/buffer/freelist.c +++ b/src/backend/storage/buffer/freelist.c @@ -555,7 +555,12 @@ GetAccessStrategy(BufferAccessStrategyType btype) return NULL; case BAS_BULKREAD: - ring_size_kb = 256; + + /* + * FIXME: Temporary increase to allow large enough streaming reads + * to actually benefit from AIO. This needs a better solution. + */ + ring_size_kb = 2 * 1024; break; case BAS_BULKWRITE: ring_size_kb = 16 * 1024; -- 2.48.1.76.g4e746b1a31.dirty --vsphh7g5lukufvxs-- ^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH v2.1 20/20] Temporary: Increase BAS_BULKREAD size @ 2024-09-01 04:42 Andres Freund <[email protected]> 0 siblings, 0 replies; 17+ messages in thread From: Andres Freund @ 2024-09-01 04:42 UTC (permalink / raw) Without this we only can execute very little AIO for sequential scans, as there's just not enough buffers in the ring. This isn't the right fix, as just increasing the ring size can have negative performance implications in workloads where the kernel has all the data cached. Author: Reviewed-By: Discussion: https://postgr.es/m/ Backpatch: --- src/backend/storage/buffer/freelist.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/backend/storage/buffer/freelist.c b/src/backend/storage/buffer/freelist.c index dffdd57e9b5..5be8125ad3a 100644 --- a/src/backend/storage/buffer/freelist.c +++ b/src/backend/storage/buffer/freelist.c @@ -555,7 +555,11 @@ GetAccessStrategy(BufferAccessStrategyType btype) return NULL; case BAS_BULKREAD: - ring_size_kb = 256; + /* + * FIXME: Temporary increase to allow large enough streaming reads + * to actually benefit from AIO. This needs a better solution. + */ + ring_size_kb = 2 * 1024; break; case BAS_BULKWRITE: ring_size_kb = 16 * 1024; -- 2.45.2.827.g557ae147e6 --ggp33qz5xusicvk6-- ^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH v2.5 28/30] Temporary: Increase BAS_BULKREAD size @ 2024-09-01 04:42 Andres Freund <[email protected]> 0 siblings, 0 replies; 17+ messages in thread From: Andres Freund @ 2024-09-01 04:42 UTC (permalink / raw) Without this we only can execute very little AIO for sequential scans, as there's just not enough buffers in the ring. This isn't the right fix, as just increasing the ring size can have negative performance implications in workloads where the kernel has all the data cached. Author: Reviewed-By: Discussion: https://postgr.es/m/ Backpatch: --- src/backend/storage/buffer/freelist.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/backend/storage/buffer/freelist.c b/src/backend/storage/buffer/freelist.c index 336715b6c63..b72a5957a20 100644 --- a/src/backend/storage/buffer/freelist.c +++ b/src/backend/storage/buffer/freelist.c @@ -555,7 +555,12 @@ GetAccessStrategy(BufferAccessStrategyType btype) return NULL; case BAS_BULKREAD: - ring_size_kb = 256; + + /* + * FIXME: Temporary increase to allow large enough streaming reads + * to actually benefit from AIO. This needs a better solution. + */ + ring_size_kb = 2 * 1024; break; case BAS_BULKWRITE: ring_size_kb = 16 * 1024; -- 2.48.1.76.g4e746b1a31.dirty --abvteypvk35ocehs Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v2.5-0029-WIP-Use-MAP_POPULATE.patch" ^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH v2 19/20] Temporary: Increase BAS_BULKREAD size @ 2024-09-01 04:42 Andres Freund <[email protected]> 0 siblings, 0 replies; 17+ messages in thread From: Andres Freund @ 2024-09-01 04:42 UTC (permalink / raw) Without this we only can execute very little AIO for sequential scans, as there's just not enough buffers in the ring. This isn't the right fix, as just increasing the ring size can have negative performance implications in workloads where the kernel has all the data cached. Author: Reviewed-By: Discussion: https://postgr.es/m/ Backpatch: --- src/backend/storage/buffer/freelist.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/backend/storage/buffer/freelist.c b/src/backend/storage/buffer/freelist.c index dffdd57e9b5..f5795b509c7 100644 --- a/src/backend/storage/buffer/freelist.c +++ b/src/backend/storage/buffer/freelist.c @@ -555,7 +555,12 @@ GetAccessStrategy(BufferAccessStrategyType btype) return NULL; case BAS_BULKREAD: - ring_size_kb = 256; + + /* + * FIXME: Temporary increase to allow large enough streaming reads + * to actually benefit from AIO. This needs a better solution. + */ + ring_size_kb = 2 * 1024; break; case BAS_BULKWRITE: ring_size_kb = 16 * 1024; -- 2.45.2.746.g06e570c0df.dirty --oy2jwuii6tssbict Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v2-0020-WIP-Use-MAP_POPULATE.patch" ^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH v2.3 28/30] Temporary: Increase BAS_BULKREAD size @ 2024-09-01 04:42 Andres Freund <[email protected]> 0 siblings, 0 replies; 17+ messages in thread From: Andres Freund @ 2024-09-01 04:42 UTC (permalink / raw) Without this we only can execute very little AIO for sequential scans, as there's just not enough buffers in the ring. This isn't the right fix, as just increasing the ring size can have negative performance implications in workloads where the kernel has all the data cached. Author: Reviewed-By: Discussion: https://postgr.es/m/ Backpatch: --- src/backend/storage/buffer/freelist.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/backend/storage/buffer/freelist.c b/src/backend/storage/buffer/freelist.c index 1f757d96f07..ac19fb87433 100644 --- a/src/backend/storage/buffer/freelist.c +++ b/src/backend/storage/buffer/freelist.c @@ -555,7 +555,12 @@ GetAccessStrategy(BufferAccessStrategyType btype) return NULL; case BAS_BULKREAD: - ring_size_kb = 256; + + /* + * FIXME: Temporary increase to allow large enough streaming reads + * to actually benefit from AIO. This needs a better solution. + */ + ring_size_kb = 2 * 1024; break; case BAS_BULKWRITE: ring_size_kb = 16 * 1024; -- 2.48.1.76.g4e746b1a31.dirty --gbq4ah2rmhae7qhd Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v2.3-0029-WIP-Use-MAP_POPULATE.patch" ^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH v2.0 17/17] Temporary: Increase BAS_BULKREAD size @ 2024-09-01 04:42 Andres Freund <[email protected]> 0 siblings, 0 replies; 17+ messages in thread From: Andres Freund @ 2024-09-01 04:42 UTC (permalink / raw) Without this we only can execute very little AIO for sequential scans, as there's just not enough buffers in the ring. This isn't the right fix, as just increasing the ring size can have negative performance implications in workloads where the kernel has all the data cached. Author: Reviewed-By: Discussion: https://postgr.es/m/ Backpatch: --- src/backend/storage/buffer/freelist.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/backend/storage/buffer/freelist.c b/src/backend/storage/buffer/freelist.c index dffdd57e9b5..5be8125ad3a 100644 --- a/src/backend/storage/buffer/freelist.c +++ b/src/backend/storage/buffer/freelist.c @@ -555,7 +555,11 @@ GetAccessStrategy(BufferAccessStrategyType btype) return NULL; case BAS_BULKREAD: - ring_size_kb = 256; + /* + * FIXME: Temporary increase to allow large enough streaming reads + * to actually benefit from AIO. This needs a better solution. + */ + ring_size_kb = 2 * 1024; break; case BAS_BULKWRITE: ring_size_kb = 16 * 1024; -- 2.45.2.827.g557ae147e6 --ww2auydviafoh7lh-- ^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH v2.4 27/29] Temporary: Increase BAS_BULKREAD size @ 2024-09-01 04:42 Andres Freund <[email protected]> 0 siblings, 0 replies; 17+ messages in thread From: Andres Freund @ 2024-09-01 04:42 UTC (permalink / raw) Without this we only can execute very little AIO for sequential scans, as there's just not enough buffers in the ring. This isn't the right fix, as just increasing the ring size can have negative performance implications in workloads where the kernel has all the data cached. Author: Reviewed-By: Discussion: https://postgr.es/m/ Backpatch: --- src/backend/storage/buffer/freelist.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/backend/storage/buffer/freelist.c b/src/backend/storage/buffer/freelist.c index 336715b6c63..b72a5957a20 100644 --- a/src/backend/storage/buffer/freelist.c +++ b/src/backend/storage/buffer/freelist.c @@ -555,7 +555,12 @@ GetAccessStrategy(BufferAccessStrategyType btype) return NULL; case BAS_BULKREAD: - ring_size_kb = 256; + + /* + * FIXME: Temporary increase to allow large enough streaming reads + * to actually benefit from AIO. This needs a better solution. + */ + ring_size_kb = 2 * 1024; break; case BAS_BULKWRITE: ring_size_kb = 16 * 1024; -- 2.48.1.76.g4e746b1a31.dirty --4ckqsto27zwk2eqr Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v2.4-0028-WIP-Use-MAP_POPULATE.patch" ^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH v2.6 32/34] Temporary: Increase BAS_BULKREAD size @ 2024-09-01 04:42 Andres Freund <[email protected]> 0 siblings, 0 replies; 17+ messages in thread From: Andres Freund @ 2024-09-01 04:42 UTC (permalink / raw) Without this we only can execute very little AIO for sequential scans, as there's just not enough buffers in the ring. This isn't the right fix, as just increasing the ring size can have negative performance implications in workloads where the kernel has all the data cached. Author: Reviewed-By: Discussion: https://postgr.es/m/ Backpatch: --- src/backend/storage/buffer/freelist.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/backend/storage/buffer/freelist.c b/src/backend/storage/buffer/freelist.c index 336715b6c63..b72a5957a20 100644 --- a/src/backend/storage/buffer/freelist.c +++ b/src/backend/storage/buffer/freelist.c @@ -555,7 +555,12 @@ GetAccessStrategy(BufferAccessStrategyType btype) return NULL; case BAS_BULKREAD: - ring_size_kb = 256; + + /* + * FIXME: Temporary increase to allow large enough streaming reads + * to actually benefit from AIO. This needs a better solution. + */ + ring_size_kb = 2 * 1024; break; case BAS_BULKWRITE: ring_size_kb = 16 * 1024; -- 2.48.1.76.g4e746b1a31.dirty --6g5xner6ro2tsnwz Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v2.6-0033-WIP-Use-MAP_POPULATE.patch" ^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH v2.8 35/38] Temporary: Increase BAS_BULKREAD size @ 2024-09-01 04:42 Andres Freund <[email protected]> 0 siblings, 0 replies; 17+ messages in thread From: Andres Freund @ 2024-09-01 04:42 UTC (permalink / raw) Without this we only can execute very little AIO for sequential scans, as there's just not enough buffers in the ring. This isn't the right fix, as just increasing the ring size can have negative performance implications in workloads where the kernel has all the data cached. Author: Reviewed-By: Discussion: https://postgr.es/m/ Backpatch: --- src/backend/storage/buffer/freelist.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/backend/storage/buffer/freelist.c b/src/backend/storage/buffer/freelist.c index 336715b6c63..b72a5957a20 100644 --- a/src/backend/storage/buffer/freelist.c +++ b/src/backend/storage/buffer/freelist.c @@ -555,7 +555,12 @@ GetAccessStrategy(BufferAccessStrategyType btype) return NULL; case BAS_BULKREAD: - ring_size_kb = 256; + + /* + * FIXME: Temporary increase to allow large enough streaming reads + * to actually benefit from AIO. This needs a better solution. + */ + ring_size_kb = 2 * 1024; break; case BAS_BULKWRITE: ring_size_kb = 16 * 1024; -- 2.48.1.76.g4e746b1a31.dirty --ow5flh3n247znjrs Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v2.8-0036-WIP-Use-MAP_POPULATE.patch" ^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH v2.9 27/30] Temporary: Increase BAS_BULKREAD size @ 2025-03-15 16:29 Andres Freund <[email protected]> 0 siblings, 0 replies; 17+ messages in thread From: Andres Freund @ 2025-03-15 16:29 UTC (permalink / raw) Without this we only can execute very little AIO for sequential scans, as there's just not enough buffers in the ring. This isn't the right fix, as just increasing the ring size can have negative performance implications in workloads where the kernel has all the data cached. Author: Reviewed-By: Discussion: https://postgr.es/m/ Backpatch: --- src/backend/storage/buffer/freelist.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/backend/storage/buffer/freelist.c b/src/backend/storage/buffer/freelist.c index 336715b6c63..b72a5957a20 100644 --- a/src/backend/storage/buffer/freelist.c +++ b/src/backend/storage/buffer/freelist.c @@ -555,7 +555,12 @@ GetAccessStrategy(BufferAccessStrategyType btype) return NULL; case BAS_BULKREAD: - ring_size_kb = 256; + + /* + * FIXME: Temporary increase to allow large enough streaming reads + * to actually benefit from AIO. This needs a better solution. + */ + ring_size_kb = 2 * 1024; break; case BAS_BULKWRITE: ring_size_kb = 16 * 1024; -- 2.48.1.76.g4e746b1a31.dirty --23jbdfobqrqxnmx5 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v2.9-0028-WIP-Use-MAP_POPULATE.patch" ^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH v2.11 25/27] Temporary: Increase BAS_BULKREAD size @ 2025-03-18 18:40 Andres Freund <[email protected]> 0 siblings, 0 replies; 17+ messages in thread From: Andres Freund @ 2025-03-18 18:40 UTC (permalink / raw) Without this we only can execute very little AIO for sequential scans, as there's just not enough buffers in the ring. This isn't the right fix, as just increasing the ring size can have negative performance implications in workloads where the kernel has all the data cached. Author: Reviewed-By: Discussion: https://postgr.es/m/ Backpatch: --- src/backend/storage/buffer/freelist.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/backend/storage/buffer/freelist.c b/src/backend/storage/buffer/freelist.c index 336715b6c63..b72a5957a20 100644 --- a/src/backend/storage/buffer/freelist.c +++ b/src/backend/storage/buffer/freelist.c @@ -555,7 +555,12 @@ GetAccessStrategy(BufferAccessStrategyType btype) return NULL; case BAS_BULKREAD: - ring_size_kb = 256; + + /* + * FIXME: Temporary increase to allow large enough streaming reads + * to actually benefit from AIO. This needs a better solution. + */ + ring_size_kb = 2 * 1024; break; case BAS_BULKWRITE: ring_size_kb = 16 * 1024; -- 2.48.1.76.g4e746b1a31.dirty --bjnmbpad43bpmfxt Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v2.11-0026-WIP-Use-MAP_POPULATE.patch" ^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH v2.12 25/28] Temporary: Increase BAS_BULKREAD size @ 2025-03-18 18:40 Andres Freund <[email protected]> 0 siblings, 0 replies; 17+ messages in thread From: Andres Freund @ 2025-03-18 18:40 UTC (permalink / raw) Without this we only can execute very little AIO for sequential scans, as there's just not enough buffers in the ring. This isn't the right fix, as just increasing the ring size can have negative performance implications in workloads where the kernel has all the data cached. Author: Reviewed-By: Discussion: https://postgr.es/m/ Backpatch: --- src/backend/storage/buffer/freelist.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/backend/storage/buffer/freelist.c b/src/backend/storage/buffer/freelist.c index 336715b6c63..b72a5957a20 100644 --- a/src/backend/storage/buffer/freelist.c +++ b/src/backend/storage/buffer/freelist.c @@ -555,7 +555,12 @@ GetAccessStrategy(BufferAccessStrategyType btype) return NULL; case BAS_BULKREAD: - ring_size_kb = 256; + + /* + * FIXME: Temporary increase to allow large enough streaming reads + * to actually benefit from AIO. This needs a better solution. + */ + ring_size_kb = 2 * 1024; break; case BAS_BULKWRITE: ring_size_kb = 16 * 1024; -- 2.48.1.76.g4e746b1a31.dirty --5i73spx2p4vwf7fe Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v2.12-0026-WIP-Use-MAP_POPULATE.patch" ^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH v2.15 15/18] Temporary: Increase BAS_BULKREAD size @ 2025-03-18 18:40 Andres Freund <[email protected]> 0 siblings, 0 replies; 17+ messages in thread From: Andres Freund @ 2025-03-18 18:40 UTC (permalink / raw) Without this we only can execute very little AIO for sequential scans, as there's just not enough buffers in the ring. This isn't the right fix, as just increasing the ring size can have negative performance implications in workloads where the kernel has all the data cached. Author: Reviewed-By: Discussion: https://postgr.es/m/ Backpatch: --- src/backend/storage/buffer/freelist.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/backend/storage/buffer/freelist.c b/src/backend/storage/buffer/freelist.c index 336715b6c63..b72a5957a20 100644 --- a/src/backend/storage/buffer/freelist.c +++ b/src/backend/storage/buffer/freelist.c @@ -555,7 +555,12 @@ GetAccessStrategy(BufferAccessStrategyType btype) return NULL; case BAS_BULKREAD: - ring_size_kb = 256; + + /* + * FIXME: Temporary increase to allow large enough streaming reads + * to actually benefit from AIO. This needs a better solution. + */ + ring_size_kb = 2 * 1024; break; case BAS_BULKWRITE: ring_size_kb = 16 * 1024; -- 2.48.1.76.g4e746b1a31.dirty --xevce4sdbnyxplun Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v2.15-0016-WIP-Use-MAP_POPULATE.patch" ^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH v2.13 25/28] Temporary: Increase BAS_BULKREAD size @ 2025-03-18 18:40 Andres Freund <[email protected]> 0 siblings, 0 replies; 17+ messages in thread From: Andres Freund @ 2025-03-18 18:40 UTC (permalink / raw) Without this we only can execute very little AIO for sequential scans, as there's just not enough buffers in the ring. This isn't the right fix, as just increasing the ring size can have negative performance implications in workloads where the kernel has all the data cached. Author: Reviewed-By: Discussion: https://postgr.es/m/ Backpatch: --- src/backend/storage/buffer/freelist.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/backend/storage/buffer/freelist.c b/src/backend/storage/buffer/freelist.c index 336715b6c63..b72a5957a20 100644 --- a/src/backend/storage/buffer/freelist.c +++ b/src/backend/storage/buffer/freelist.c @@ -555,7 +555,12 @@ GetAccessStrategy(BufferAccessStrategyType btype) return NULL; case BAS_BULKREAD: - ring_size_kb = 256; + + /* + * FIXME: Temporary increase to allow large enough streaming reads + * to actually benefit from AIO. This needs a better solution. + */ + ring_size_kb = 2 * 1024; break; case BAS_BULKWRITE: ring_size_kb = 16 * 1024; -- 2.48.1.76.g4e746b1a31.dirty --pro7bqageygxfsvg Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v2.13-0026-WIP-Use-MAP_POPULATE.patch" ^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH v2.10 24/28] Temporary: Increase BAS_BULKREAD size @ 2025-03-18 18:40 Andres Freund <[email protected]> 0 siblings, 0 replies; 17+ messages in thread From: Andres Freund @ 2025-03-18 18:40 UTC (permalink / raw) Without this we only can execute very little AIO for sequential scans, as there's just not enough buffers in the ring. This isn't the right fix, as just increasing the ring size can have negative performance implications in workloads where the kernel has all the data cached. Author: Reviewed-By: Discussion: https://postgr.es/m/ Backpatch: --- src/backend/storage/buffer/freelist.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/backend/storage/buffer/freelist.c b/src/backend/storage/buffer/freelist.c index 336715b6c63..b72a5957a20 100644 --- a/src/backend/storage/buffer/freelist.c +++ b/src/backend/storage/buffer/freelist.c @@ -555,7 +555,12 @@ GetAccessStrategy(BufferAccessStrategyType btype) return NULL; case BAS_BULKREAD: - ring_size_kb = 256; + + /* + * FIXME: Temporary increase to allow large enough streaming reads + * to actually benefit from AIO. This needs a better solution. + */ + ring_size_kb = 2 * 1024; break; case BAS_BULKWRITE: ring_size_kb = 16 * 1024; -- 2.48.1.76.g4e746b1a31.dirty --w6dfit2y42fwvotd Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v2.10-0025-WIP-Use-MAP_POPULATE.patch" ^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH v2.14 26/29] Temporary: Increase BAS_BULKREAD size @ 2025-03-18 18:40 Andres Freund <[email protected]> 0 siblings, 0 replies; 17+ messages in thread From: Andres Freund @ 2025-03-18 18:40 UTC (permalink / raw) Without this we only can execute very little AIO for sequential scans, as there's just not enough buffers in the ring. This isn't the right fix, as just increasing the ring size can have negative performance implications in workloads where the kernel has all the data cached. Author: Reviewed-By: Discussion: https://postgr.es/m/ Backpatch: --- src/backend/storage/buffer/freelist.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/backend/storage/buffer/freelist.c b/src/backend/storage/buffer/freelist.c index 336715b6c63..b72a5957a20 100644 --- a/src/backend/storage/buffer/freelist.c +++ b/src/backend/storage/buffer/freelist.c @@ -555,7 +555,12 @@ GetAccessStrategy(BufferAccessStrategyType btype) return NULL; case BAS_BULKREAD: - ring_size_kb = 256; + + /* + * FIXME: Temporary increase to allow large enough streaming reads + * to actually benefit from AIO. This needs a better solution. + */ + ring_size_kb = 2 * 1024; break; case BAS_BULKWRITE: ring_size_kb = 16 * 1024; -- 2.48.1.76.g4e746b1a31.dirty --m2na7lgr3zfazgom Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v2.14-0027-WIP-Use-MAP_POPULATE.patch" ^ permalink raw reply [nested|flat] 17+ messages in thread
end of thread, other threads:[~2025-03-18 18:40 UTC | newest] Thread overview: 17+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2020-12-28 08:01 [PATCH v1] generate JIT IR code lazily Luc Vlaming <[email protected]> 2024-09-01 04:42 [PATCH v2.7 33/35] Temporary: Increase BAS_BULKREAD size Andres Freund <[email protected]> 2024-09-01 04:42 [PATCH v2.1 20/20] Temporary: Increase BAS_BULKREAD size Andres Freund <[email protected]> 2024-09-01 04:42 [PATCH v2.5 28/30] Temporary: Increase BAS_BULKREAD size Andres Freund <[email protected]> 2024-09-01 04:42 [PATCH v2 19/20] Temporary: Increase BAS_BULKREAD size Andres Freund <[email protected]> 2024-09-01 04:42 [PATCH v2.3 28/30] Temporary: Increase BAS_BULKREAD size Andres Freund <[email protected]> 2024-09-01 04:42 [PATCH v2.0 17/17] Temporary: Increase BAS_BULKREAD size Andres Freund <[email protected]> 2024-09-01 04:42 [PATCH v2.4 27/29] Temporary: Increase BAS_BULKREAD size Andres Freund <[email protected]> 2024-09-01 04:42 [PATCH v2.6 32/34] Temporary: Increase BAS_BULKREAD size Andres Freund <[email protected]> 2024-09-01 04:42 [PATCH v2.8 35/38] Temporary: Increase BAS_BULKREAD size Andres Freund <[email protected]> 2025-03-15 16:29 [PATCH v2.9 27/30] Temporary: Increase BAS_BULKREAD size Andres Freund <[email protected]> 2025-03-18 18:40 [PATCH v2.11 25/27] Temporary: Increase BAS_BULKREAD size Andres Freund <[email protected]> 2025-03-18 18:40 [PATCH v2.12 25/28] Temporary: Increase BAS_BULKREAD size Andres Freund <[email protected]> 2025-03-18 18:40 [PATCH v2.15 15/18] Temporary: Increase BAS_BULKREAD size Andres Freund <[email protected]> 2025-03-18 18:40 [PATCH v2.13 25/28] Temporary: Increase BAS_BULKREAD size Andres Freund <[email protected]> 2025-03-18 18:40 [PATCH v2.10 24/28] Temporary: Increase BAS_BULKREAD size Andres Freund <[email protected]> 2025-03-18 18:40 [PATCH v2.14 26/29] Temporary: Increase BAS_BULKREAD size Andres Freund <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox