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 1lvf8p-0000jz-Vf for pgsql-admin@arkaria.postgresql.org; Tue, 22 Jun 2021 12:04:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lvf8o-00048f-QY for pgsql-admin@arkaria.postgresql.org; Tue, 22 Jun 2021 12:04:30 +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 1lvf8o-00048X-Fz for pgsql-admin@lists.postgresql.org; Tue, 22 Jun 2021 12:04:30 +0000 Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lvf8m-0003ZT-Dy for pgsql-admin@lists.postgresql.org; Tue, 22 Jun 2021 12:04:29 +0000 Received: by mail-wr1-x42f.google.com with SMTP id i94so23330484wri.4 for ; Tue, 22 Jun 2021 05:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Di+iGx2s93hTawhHiiLA9BCkllo9Imwn7x+rTnM8uOM=; b=P+JZIbQCTY/yY4BOsCx/f6o8d8c5CRA52CedsxOWJIUZnglGQqGTujMiS886eLWHMW +cKs4+ylVe6qTEHUlemqfui1l2Ox54NlY7vb98KKPFgdixZ/d7k7TD9KGnduuXWBLKzK jFQN0hMIZsaipF79S0iRbHnOlJZR9rO8a/o/ZoMijAYow1zilWlD/KgVm5S6fpIP6Z67 LV3+sqLa8PyqM3P6qle2wf0PDeC/wCjpqfOu5xLVVcydMjs6zzqtVw7RnkdBFXV8RC5v bGywULrk3bbloaUW8tTtsWJ0xZM0Z3kyb9OWbfAV0iA/8UAq+foPiQKh2JdhDw8U4/+b 0yZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Di+iGx2s93hTawhHiiLA9BCkllo9Imwn7x+rTnM8uOM=; b=fp8J3nps5grEsIWJJ8GjzFzizhYvHbcO7fK8xSLBMyzk8sqNFS144CoT7/uWbJzrRh rs2C6kIaOD1Xq/wTR9jp1IMTpSYn+yofWtg8E4Zx831zEjKjwSc1I68ngZf0mByBKkqc 0iesEK6GQeAwHq3iSr/fs/xaDAaf4Zl/RAGtfAZmiNuO2Hg92a/Ec/lW1kWyWQHuG+nF bMklidwgsILQNItanU9wfJQcSCPrP6aiEGHN/KyPS7XULLDw4pNuVBmqroY+X+O9QNHD fP4QOCFdgYRVfQ8WUxmB8oyUCG89m6DK1BsKQb/k52FV9HxFgeiSo+yHPM43pAccAwpj hb3Q== X-Gm-Message-State: AOAM531ATKOUfNjCqfMhafi8RxsGTFqLRorYbMujgziOIxhOB6kd2Elr i11qiNIS/x2o+Gd5l6IeLT9asTXc1Ld6Ng== X-Google-Smtp-Source: ABdhPJxiabpQc8YlOsdryJ/4Cg/qPjO7NQdjxCOUI3dXCQ0HOHq1z8TO1WUuvd+yDtjrDKDB49jc9A== X-Received: by 2002:a5d:64ca:: with SMTP id f10mr4206831wri.331.1624363466276; Tue, 22 Jun 2021 05:04:26 -0700 (PDT) Received: from [192.168.1.8] (net-93-66-70-148.cust.vodafonedsl.it. [93.66.70.148]) by smtp.gmail.com with ESMTPSA id u12sm11399296wrq.50.2021.06.22.05.04.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Jun 2021 05:04:25 -0700 (PDT) Subject: Re: Temp files for simple queries To: Julien Rouhaud Cc: pgsql-admin@lists.postgresql.org References: <45cc44dd-b830-5df5-1f09-171e9874bbc0@gmail.com> <16aa733d-bcaf-0aa6-f3f0-5206de695e92@gmail.com> <20210622115506.o2u4u5krplxxc54k@nol> From: "Radoulov, Dimitre" Message-ID: <2890331e-aa23-bbef-0150-f1e374d8313b@gmail.com> Date: Tue, 22 Jun 2021 14:05:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210622115506.o2u4u5krplxxc54k@nol> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello Julien, On 22/06/2021 13.55, Julien Rouhaud wrote: > On Tue, Jun 22, 2021 at 01:51:55PM +0200, Radoulov, Dimitre wrote: >> Just to clarify: the size of the temp file is 7MB and with work_mem of 4MB >> it clearly doesn't fit. >> >> But why an "order by" of a 440kB of data would require 7MB. >> >> One possible reason is that that the number of records in that table varies >> significantly during the day, > That would be the logical explanation. You could configure auto_explain to > make sure of that (https://www.postgresql.org/docs/current/auto-explain.html). > >> but - if that's the case - I would expect that >> the table would be much bigger than 440kB (size taken using \dt+). > Not necessarily. autovacuum can truncate the file if all the trailing blocks > are empty (and if it can acquire an exclusive lock fast enough), so if some > client inserts a lot of rows, process them and remove them all, and later on > slowly start to insert new rows you will get that behavior. I thought that only a vacuum full could do that, thanks for pointing it out. Best regards Dimitre