Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pcm84-00044S-GU for pgsql-hackers@arkaria.postgresql.org; Thu, 16 Mar 2023 11:50:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pcm83-0007At-Al for pgsql-hackers@arkaria.postgresql.org; Thu, 16 Mar 2023 11:50:43 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pcm83-0007Ak-1I for pgsql-hackers@lists.postgresql.org; Thu, 16 Mar 2023 11:50:43 +0000 Received: from mail-wm1-x32b.google.com ([2a00:1450:4864:20::32b]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pcm7y-0007DG-Nd for pgsql-hackers@postgresql.org; Thu, 16 Mar 2023 11:50:42 +0000 Received: by mail-wm1-x32b.google.com with SMTP id x22so1024146wmj.3 for ; Thu, 16 Mar 2023 04:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678967437; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=zndwaW5ibUd39y8G+bejfuiHROjQk77AiZ/EPlrrYIA=; b=SuIe6H/UlV+4/D2lzsWVfwK4FH35EazTuNS3FcI9BdT4GVuhYuamqr9nmFJHpZxXJv cqVEwkZOSfoX6ZDZJ0n0kS+wic0Ak7snUpZDagXwvc5EoSxEj1nxL+hTSmzEtIGunBfj azFlqQtz03wrKULv/wROb17MWB1SWA7ZrBcmTRJo90+rqnn+jPB8d7giET/aC/vegZ6v QoyY2MWd2fzLc8aldr3DZdDv55ZJYa6zFoYLCKpZ6Z3XiUly4sCIx5wyfGPVNGK60BOO GbbEIdruWvq2M4y/KwIl4O+wEwSoagXpiSKxBEMui1RitfoU/th9799vHhkkFBx7QT1q Z6Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678967437; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=zndwaW5ibUd39y8G+bejfuiHROjQk77AiZ/EPlrrYIA=; b=rCWBqRNEvzPl9+7xZ1UJqPX6azlNZ2ByldKWFDA2xJ8JZO7SMab0Zw5xItGVknKci5 vhdgxYoOuz2dX+kAxziLxRGh8nrf/KUloxxf5DyBVKPfseAebqb9BElYGmOaPu6o+KpJ z+5VfN8Tvh8PjbIuyVm5XAJTFlTRAGlRkrAbPQTkkT0nVu88hRUERxrikyjC44HleA69 oHsXTVU8Pl/2Se7b0pKM26OXi/bCl/9J60Lif0clPhNFFIgF9/8COlD+MOIA3OX1TPgy IXCMKyCbPAdHyd0FphdQQ0qIYW0FeNwIvqZOQV6o2c99kRcV1wtVHdIX5w9KdNUHDZ5y 0Quw== X-Gm-Message-State: AO0yUKXa3SQ14yUMwdo3gEFgrkqy54jTn1rS5J2IdkOBOIPabPnnBeEF a51aWo9PKzikBGxIvqAxu2g= X-Google-Smtp-Source: AK7set89xrxyf6KKLV0Mifjahyfm2F5B/gGec2JFxl/clCqaKhG5vN5M+R/+M3umU94VavH7bLhHfw== X-Received: by 2002:a05:600c:46c6:b0:3ed:4c36:aeb9 with SMTP id q6-20020a05600c46c600b003ed4c36aeb9mr2063427wmo.29.1678967437132; Thu, 16 Mar 2023 04:50:37 -0700 (PDT) Received: from [192.168.22.74] ([54.239.6.186]) by smtp.gmail.com with ESMTPSA id t8-20020a1c7708000000b003ed2276cd0dsm4700063wmi.38.2023.03.16.04.50.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Mar 2023 04:50:36 -0700 (PDT) Message-ID: <2c449944-443d-b093-224d-73b21f19d456@gmail.com> Date: Thu, 16 Mar 2023 12:50:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: Speed-up shared buffers prewarming Content-Language: en-US To: Matthias van de Meent , Konstantin Knizhnik Cc: PostgreSQL Hackers References: From: "Drouvot, Bertrand" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On 3/15/23 10:40 PM, Matthias van de Meent wrote: > On Wed, 15 Mar 2023 at 21:38, Konstantin Knizhnik wrote: >> >> Hi hackers, >> >> It is well known fact that queries using sequential scan can not be used to prewarm cache, because them are using ring buffer >> even if shared buffers are almost empty. >> I have searched hackers archive but failed to find any discussion about it. >> What are the drawbacks of using free buffers even with BAM_BULKREAD strategy? >> I mean the following trivial patch: >> >> diff --git a/src/backend/storage/buffer/freelist.c b/src/backend/storage/buffer/freelist.c >> index 6be80476db..243335d0e4 100644 >> --- a/src/backend/storage/buffer/freelist.c >> +++ b/src/backend/storage/buffer/freelist.c >> @@ -208,8 +208,15 @@ StrategyGetBuffer(BufferAccessStrategy strategy, uint32 *buf_state) >> /* >> * If given a strategy object, see whether it can select a buffer. We >> * assume strategy objects don't need buffer_strategy_lock. >> */ >> - if (strategy != NULL) >> + if (strategy != NULL && StrategyControl->firstFreeBuffer < 0) >> { >> buf = GetBufferFromRing(strategy, buf_state); >> if (buf != NULL) >> >> So if there are free buffers, then use normal buffer allocation instead of GetBufferFromRing. > > Yes. As seen in [1], ring buffers aren't all that great in some cases, > and I think this is one. Buffer allocation should always make use of > the available resources, so that it doesn't take O(N/ring_size) scans > on a table to fill the buffers if that seqscan is the only workload of > the system. Agree but then what do you think about also paying special attention to those buffers when eviction needs to be done? Those buffers are "usually" needed briefly, so something like being able to distinguish them and be more aggressive regarding their eviction. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com