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 1mKmmd-0004Os-96 for pgsql-admin@arkaria.postgresql.org; Mon, 30 Aug 2021 19:17:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mKmmc-0007NM-30 for pgsql-admin@arkaria.postgresql.org; Mon, 30 Aug 2021 19:17:26 +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 1mKmmb-0007ND-Qa for pgsql-admin@lists.postgresql.org; Mon, 30 Aug 2021 19:17:25 +0000 Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mKmmU-0002Z3-NX for pgsql-admin@lists.postgresql.org; Mon, 30 Aug 2021 19:17:24 +0000 Received: by mail-wr1-x436.google.com with SMTP id n5so23848129wro.12 for ; Mon, 30 Aug 2021 12:17:18 -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:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=VMHbpnZLVTQ1WfTpfzmAtxPQBrxzkGYcmQY6Ug8sASA=; b=O8kygbHU8rG6RKhguqChGCwh8eEHFBjIV0QQUTnrpRzDFzVZ9DV1biTsi2OJGzDIwF LJcx/GdM50bYsdIQ37mexgCe8wnhOt6iwUoLTWiTvXI0u8QoCze42YjyfwDJW/VoEags C4+WVBhy/iBrmn+rzOahyrhapdr9DitQO/5vzMQ9cgAiAaLaNr5XFcVqWej1TCII1HCq W1pn+KA7S6u1+i/vOjj1vX4qIE/wGCr8Nw49NmbRVKQVrXsFqACsFyUccLk7chlc+Rsc WS/szhZI9Xcnq6F2uWzjc6HposYfPdbzejCLl+UoNFAK+NRNJyekvp9Jgz1oDddNg0RW jsRA== 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:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=VMHbpnZLVTQ1WfTpfzmAtxPQBrxzkGYcmQY6Ug8sASA=; b=GMSp9md4HsGg/i8oTv5+tycSPHR9ZAVmVAhTN2k6f2Knh2Ium59yHNBn52AG9ZIvlw TArxUQrKjsRd31dzOv6eYJj5vwP76fmWN8N1PKo8KRqxitm3jRiwbHGiF11pDlirN7Ga 2lvMAlZq+zp+N8Rr6xmhVC3HdSEfqGU2lm7a7MSwTWqoy0J0YROKtTn7x0ovQAUc8SMz lCSYRsp9JbBjYpLrzDdpPVEcf7qTza9NJHMFLYOv5H7fmqfqRZQ4cxxyaSajcHLTe4On /AUpa7Qw/jrT1oQ3Pqk5I8LQS66f59idEteO4GaBWYzYB22/K4B9BFGhTzJngwT5VZIy SMGg== X-Gm-Message-State: AOAM532ozzLxgdaZ2BomJ3SkaqUEA5HKrdUNirf3XWv2jXbAzNQRP7q6 axIBrmXDKbvFNgf/6Zxfs0iNkglDcEg/rw== X-Google-Smtp-Source: ABdhPJxffC3MYcfXSdBN45XC+094x7rQpH9ETrJoWFQfoULj1Tbc7f8ro24lgdytHhCV44J0Ne1fMw== X-Received: by 2002:adf:80eb:: with SMTP id 98mr20301836wrl.348.1630351036202; Mon, 30 Aug 2021 12:17:16 -0700 (PDT) Received: from localhost.localdomain (dynamic-e0r6tpdevjvdg5mlb-pd01.res.v6.highway.a1.net. [2001:871:5c:4db9:cf7b:7421:7101:159f]) by smtp.gmail.com with ESMTPSA id u2sm336852wmj.29.2021.08.30.12.17.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Aug 2021 12:17:15 -0700 (PDT) Message-ID: <22b33dc4789bb9ff9b260407d02cd83837c4a3b7.camel@cybertec.at> Subject: Re: vacuumlo From: Laurenz Albe To: Mladen Gogala , pgsql-admin@lists.postgresql.org Date: Mon, 30 Aug 2021 21:17:15 +0200 In-Reply-To: References: <9395a02bc37b8c7a3ca09441d288ff49e1c19c39.camel@cybertec.at> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 (3.40.4-1.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, 2021-08-30 at 13:38 -0400, Mladen Gogala wrote: > According to unsubstantiated rumors from https://www.postgresql.org/docs/13/catalog-pg-class.html, > the definition of RELFILENODE column is as follows: > >  relfilenode oid > > Name of the on-disk file of this relation; zero means this is a “mapped” relation whose disk > file name is determined by low-level state > Change of the RELFILENODE means that the relation has got a new file. And that means that vacuum full > rewrites the table, just as Laurenz has said. Note that OID itself is NOT changed. Please don't top-post on these lists. I am not sure what you mean with "unsubstantiated". Note that this will be 0 for certain crucial system tables (essentially those that have to be accessed *before* regular metadata queries can be executed). So it is better to use the "pg_relation_filenode()" function to find the file that belongs to a certain table. You can use that to find which files do *not* belong to any table, index, sequence or materialized view and then delete those. But I would think twice before manually deleting files in the data directory. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com