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 1lRCKv-0007l1-H4 for pgsql-novice@arkaria.postgresql.org; Tue, 30 Mar 2021 11:15:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lRCKu-0006KA-8r for pgsql-novice@arkaria.postgresql.org; Tue, 30 Mar 2021 11:15:04 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lRCKu-0006K2-2B for pgsql-novice@lists.postgresql.org; Tue, 30 Mar 2021 11:15:04 +0000 Received: from mail-ed1-x52a.google.com ([2a00:1450:4864:20::52a]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lRCKq-0003Ii-VW for pgsql-novice@postgresql.org; Tue, 30 Mar 2021 11:15:02 +0000 Received: by mail-ed1-x52a.google.com with SMTP id w18so17812287edc.0 for ; Tue, 30 Mar 2021 04:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=acMTzFZA2GOG1DavPcXP/22nqUm3eN0gV7bZ74E8O8A=; b=wcNVnzUT7WnOe4VJgAIVO69XpcZzBjJ8J53CLxlUgYMq/Zdljloe4zxNv8DfE+umVP ai5EPeQO8xTdHvkM5wub9d+MgsL2py8quTi5nQYlfzPJpPCKeVumHT5D70+EdTDDHThH 4wUeahefpLhoRcGUZtqC8tgb5YZ5A5EXlvQUUkrnMvlcygsErT8CNrNYCtzTmYeHmSGZ 54UII52yTKdZposq8zxHtyv4ozEPPrm6W6psJ2u2FHwTF4tjT9a+MAvyoUogsvMjmaoZ RktVb1RWIv2b5auUpt5cDkTwuKqDuQO3QNB/QDFoOZI7+n5nEM5TWIXyu2yh6T2jDi+q EYmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=acMTzFZA2GOG1DavPcXP/22nqUm3eN0gV7bZ74E8O8A=; b=Tp4XVzvDr/BdS4qyzyfgYOyhFsB7P3E/RhUlTMzDx3sjhD2XGQlD2zhzSut/h+5Bft 9mIk1SdHKjPbUZ6O2j0rqxHmyjxrtc50CnM3A+mOBvlQ6XWle4cDQtow6NGaQdbAgXXE T5Kvws9D/yyDgeRpjnz2zQQJoMVQEts+D068+i3Itjdb2w9SXGiP/Ekfwt7RL+ro9HSQ sjFNkt9kp89xktiTCroVOt211ssLIojiY4aC99jZtFNQBMNPwDqnRdjrqqxS3RQMVwIX bTUFIorSF/eTqxMO4GKyDfHbmc87HJ04bjkS6EWa9zsxcp567/J6SMezPu7KfHic8Upw /9Qw== X-Gm-Message-State: AOAM5315osUeJmeJ8BbqJ0OjMCPldcZ5WwUUU5ti0n/KbrbyWMOu6laa /vpvrloLvhilgidSMZJVw3pG9A== X-Google-Smtp-Source: ABdhPJzOBLfHiY8zGAthpxUk9MlnUEAfYPcUEryujnkb17PQUyxYhdHNmEvJEb89/8rxRQ7oREVzrg== X-Received: by 2002:a05:6402:699:: with SMTP id f25mr33354448edy.47.1617102899123; Tue, 30 Mar 2021 04:14:59 -0700 (PDT) Received: from localhost.localdomain (217-149-168-246.nat.highway.telekom.at. [217.149.168.246]) by smtp.gmail.com with ESMTPSA id bm10sm11114653edb.2.2021.03.30.04.14.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Mar 2021 04:14:58 -0700 (PDT) Message-ID: <7b12ce640429a5b286b39342998b47fed74fafec.camel@cybertec.at> Subject: Re: shared buffers From: Laurenz Albe To: Greg Rychlewski Cc: pgsql-novice@postgresql.org Date: Tue, 30 Mar 2021 13:14:55 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, 2021-03-29 at 14:04 -0400, Greg Rychlewski wrote: > > > Will every page touched during a table or index scan, even if it's > > > not going to be used in the final result, be loaded into shared buffers? > > > > > > i.e. if you need to evaluate a filter condition, will it load that page > > > into shared buffers and then evaluate it from there? > > > > Even if a value does not appear in a query result, the page containing it > > has to be read, if the value is used for calculating the query result. > > > > All pages read are loaded into shared buffers. So yes, they will be loaded. > > > > Note that there is an optimization for big sequential scans: if the table > > scanned is bigger than a quarter of shared buffers, PostgreSQL will use a > > small ring buffer to read the table. This prevents a large sequential scan > > from blowing out your cache, since it uses the same buffers to scan > > the whole table. > > Oh that's really interesting about the ring buffer. So if you're doing an > update/delete/insert that requires the ring buffer, does that mean the > backend itself will write to disk instead of the > checkpoint process? That is only used for reading. All reading and writing is *always* done through shared buffers. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com