Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sVtWa-00CCRG-Uv for pgsql-admin@arkaria.postgresql.org; Mon, 22 Jul 2024 13:56:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sVtWY-002PA1-78 for pgsql-admin@arkaria.postgresql.org; Mon, 22 Jul 2024 13:56:22 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sVtWX-002P9o-SY for pgsql-admin@lists.postgresql.org; Mon, 22 Jul 2024 13:56:22 +0000 Received: from mailout.easymail.ca ([64.68.200.34]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sVtWW-000t1J-0p for pgsql-admin@lists.postgresql.org; Mon, 22 Jul 2024 13:56:21 +0000 Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 44BC7619F8; Mon, 22 Jul 2024 13:56:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elevated-dev.com; s=easymail; t=1721656578; bh=kgHDbVUswY4ifV8viDk8U21JgNUDSXrAXbD9w2w6leY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Gs8UhOakGNE4A9laM2poFJyp64IZfdXCcY4RN6Z8aOtSbjgOUe23MFb0b6yguZ8BL xOsSAJyQZV6aaiVbD+jLMyXE7rRRuxs4ltnKrH1eLRAsNAk+Ug2d9iUYYAcPumWXcu bbYlUx7TT8CaOVzrQabcU3VE1j60hhxGeBJ2ITxpSxB72yX7flkzXlR5g0WUJheOxu /cXNc17hDIB6mhRAACmw/bPZJHkjIyFV88esORkqea/DMcQb8IDSCLk+BoPZK9my/7 yt01AK9pAEvHuY/raYYyZOs7beWvwzZPi82FTnQOVnlITPBTE2M037lIO7xiFbgoBC cJz8hSfkzkYKg== X-Virus-Scanned: Debian amavisd-new at emo07-pco.easydns.vpn Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo07-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjIpNlNHUP1P; Mon, 22 Jul 2024 13:56:17 +0000 (UTC) Received: from smtpclient.apple (unknown [165.140.184.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id A5CA7619C1; Mon, 22 Jul 2024 13:56:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elevated-dev.com; s=easymail; t=1721656577; bh=kgHDbVUswY4ifV8viDk8U21JgNUDSXrAXbD9w2w6leY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=dwLv30kDy2uUvqks/rHX+1cw8OqzHmeJveA/1Rq68VQYxgDQgncSCjG2SFJWjMTRR ftUIfH3fyxm8ld6vCHkiYwWZEnHTr8HScNtnjr6s9I649D6JOL6NGiJ2rnzop2pilA Ix0T6m+WC6YUiJZeSTc2UdibzoKBqUzKYpY8ywO2/sMGj4h7eW2vyNdfJMhjZ5Z7yP YJvGt2sjycUGL/ZpHr6yJD8WamTCN/Stj5K6tIar8mva/AMK54oS2HCMFhpsymCxJC 3H6tzVRC2Ua9+DM7ziZ+gRl9QkMzblAzUK63Ox4HJPnrWauOJLHImXMaUwuZRLXqtH tnjAUfattbxFQ== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: small temp files From: Scott Ribe In-Reply-To: Date: Mon, 22 Jul 2024 07:56:06 -0600 Cc: pgsql-admin@lists.postgresql.org Content-Transfer-Encoding: quoted-printable Message-Id: <6C269096-47A8-4F23-87AC-512656D4A084@elevated-dev.com> References: <7A0C9A69-5632-4CFC-B156-53FAAAB33E26@elevated-dev.com> <8E03B792-C389-456D-913D-4F2B0EBB903E@elevated-dev.com> To: Paul Smith* , "David G. Johnston" X-Mailer: Apple Mail (2.3774.600.62) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > ...with each operation generally being allowed to use as much memory = as this value specifies before it starts to write data into temporary = files. So, doesn't explain the 7452-byte files. Unless an operation can use a = temporary file as an addendum to work_mem, instead of spilling the RAM = contents to disk as is my understanding. > So, if it's doing lots of joins, there may be lots of bits of = temporary data which together add up to more than work_mem. If it's doing lots of joins, each will get work_mem--there is no "adding = up" among operations using work_mem. > You expect the smallest temporary file to be 128MB? I.e., if the = memory used exceeds work_mem all of it gets put into the temp file at = that point? Versus only the amount of data that exceeds work_mem = getting pushed out to the temporary file. The overflow only design = seems much more reasonable - why write to disk that which fits, and = already exists, in memory. Well, I don't know of an algorithm which can effectively sort 128MB + = 7KB of data using 128MB of RAM and a 7KB file. Same for many of the = other operations which use work_mem, so yes, I expected spill over to = start with 128MB file and grow it as needed. If I'm wrong and there are = operations which can effectively use temp files as adjunct, then that = would be the answer to my question. Does anybody know for sure that this = is the case?=