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 1q69JD-00064y-Lo for pgsql-novice@arkaria.postgresql.org; Mon, 05 Jun 2023 12:27:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1q69JB-000076-Gc for pgsql-novice@arkaria.postgresql.org; Mon, 05 Jun 2023 12:27:37 +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 1q69J8-0008Vt-9v for pgsql-novice@lists.postgresql.org; Mon, 05 Jun 2023 12:27:37 +0000 Received: from mail-qt1-x82d.google.com ([2607:f8b0:4864:20::82d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1q69J2-000N7h-4S for pgsql-novice@lists.postgresql.org; Mon, 05 Jun 2023 12:27:33 +0000 Received: by mail-qt1-x82d.google.com with SMTP id d75a77b69052e-3f7d72d54a1so10205481cf.1 for ; Mon, 05 Jun 2023 05:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unochapeco.edu.br; s=google; t=1685968045; x=1688560045; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=g4DlcIwBoHjuk1hfj3vKp1GXQKJReDCEUm2iDlvzSDs=; b=CKhsiefgLjAJ4L2jDJe8g4wljnYY8AcUHKdGsmtTqRZxJwgELffxoRJCZrv3XSnNnh CAF1ncmmJiz9kKj+xDZzeHnJxm/rjOVBU5zO6S0tujvTSR+OS1rej2AVRWt7a0CprQ4n vGH+AixsuZcTHFNE4t1YyCbXeqmXwwb7zHSwlFcE76bVIgzjan3k/tAF26DqjISqJx6w 9MoA47YSs5M9ozMBBmSuPMO/8n0mzRbPFtnwTBPoL22MBmJWdbZvMQnTfEe87aNNq8cN EABI+hlNXlZnZ+wdVDXOaDmsCagVybvIU2sTgGIQPfU79OiMJg7s73b+/VtyRlEYgFne 6GBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685968045; x=1688560045; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=g4DlcIwBoHjuk1hfj3vKp1GXQKJReDCEUm2iDlvzSDs=; b=gfF1XArHkb6KxHCBcm6CZD7MV0KmSAcSAiGUxzl+S4qmb6kR9/Z1+ADOc7ezTjS2gX wp8Ql+UbhcUn+t3jpJFYv/JVCtebS6OoJatdZRuH3c+rJW4ek0PUGqPMtfttvLh2iwYY 1Nex1RnGm66MaIclJ4WfBu+zcvPmpENKvDFIkBAf0Ay9OsUVHk4JIky3RLfgcTabEGqI 0TgxadXJ3bcZmGLwui9NIxRbTHk5XJiZeFesIcxpDDTP9dq1oUExdn1y2POneQahChRa /RUxf0lJY6kXSvO6IBLYRzqekIInZjO1VCakCkL2Fa2W7OZTCsU0W6HIinpHGEI6+a9p VQYg== X-Gm-Message-State: AC+VfDzS9+/9//OR0LJjC0R+1iFETxk1vOlozCX5AS98fr5EOE4HJTOl FzxQc+6jSKVCevEYL0Q/IJ7Z59yuR8uaEtGCJm8= X-Google-Smtp-Source: ACHHUZ72uAeOteYBY7vqsUCpIk7WhVB1rqnvpd/uwHQKJZh4dWIhXgKgT3k2IR8a1MrEMAOHTsrR+g== X-Received: by 2002:a05:6870:c08e:b0:192:beba:7bd with SMTP id c14-20020a056870c08e00b00192beba07bdmr12305649oad.2.1685967606916; Mon, 05 Jun 2023 05:20:06 -0700 (PDT) Received: from smtpclient.apple ([189.39.32.185]) by smtp.gmail.com with ESMTPSA id t1-20020a056870048100b00187e500e7b3sm3484956oam.49.2023.06.05.05.20.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jun 2023 05:20:06 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\)) Subject: Re: Does PostgreSQL cache all columns of a table after SELECT? From: William Alves Da Silva In-Reply-To: <1888b7bb7fa.112313046679561.2788161417267896332@trallnag.com> Date: Mon, 5 Jun 2023 09:19:53 -0300 Cc: pgsql-novice Content-Transfer-Encoding: quoted-printable Message-Id: <686C8E94-4B50-40E1-9A5C-6500B47C3622@unochapeco.edu.br> References: <1888b7bb7fa.112313046679561.2788161417267896332@trallnag.com> To: Tim Schwenke X-Mailer: Apple Mail (2.3731.500.231) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello Tim, Can you send the EXPLAIN (BUFFERS, ANALYZE, VERBOSE) of your query? This = will show you whether the plan is using caching or not. > On 5 Jun 2023, at 09:15, Tim Schwenke wrote: >=20 > Hello, >=20 > I have the following table with the following columns: >=20 > large_a: text (few dozen characters up to a few hundred) > large_b: text (few dozen characters up to a few hundred) >=20 > The table has several million rows. The DB is running on a large = machine. >=20 > I perform the following query: >=20 > select large_a from table; >=20 > The first query takes a few minutes. Afterwards I see that the cache = in memory has grown. Next query only takes a few seconds. >=20 > What I want to know: >=20 > Does the cache also contain large_b? Or is only large_a cached? = Assumption is that memory is large enough to fit everything. >=20 >=20 >=20 Regards, William Alves=