From bc8e7e04df9fc915aff0bb36ac71cab69ff392fd Mon Sep 17 00:00:00 2001 From: Alexey Milovidov Date: Sun, 12 Jul 2020 04:05:09 +0300 Subject: [PATCH] Lower block sizes and look what will happen #9248 --- src/Core/Defines.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/Core/Defines.h b/src/Core/Defines.h index 8b26f486c9d..1f755409f2f 100644 --- a/src/Core/Defines.h +++ b/src/Core/Defines.h @@ -21,14 +21,14 @@ /** Which blocks by default read the data (by number of rows). * Smaller values give better cache locality, less consumption of RAM, but more overhead to process the query. */ -#define DEFAULT_BLOCK_SIZE 65536 +#define DEFAULT_BLOCK_SIZE 65505 /// 65536 minus 16 + 15 bytes padding that we usually have in arrays /** Which blocks should be formed for insertion into the table, if we control the formation of blocks. * (Sometimes the blocks are inserted exactly such blocks that have been read / transmitted from the outside, and this parameter does not affect their size.) * More than DEFAULT_BLOCK_SIZE, because in some tables a block of data on the disk is created for each block (quite a big thing), * and if the parts were small, then it would be costly then to combine them. */ -#define DEFAULT_INSERT_BLOCK_SIZE 1048576 +#define DEFAULT_INSERT_BLOCK_SIZE 1048545 /// 1048576 minus 16 + 15 bytes padding that we usually have in arrays /** The same, but for merge operations. Less DEFAULT_BLOCK_SIZE for saving RAM (since all the columns are read). * Significantly less, since there are 10-way mergers.