Re: Database size will be Huge difference while Restoring

On 5/22/23 04:38, Rajmohan Masa wrote:
> Hi Adrian,
> 
> I Found one thing in my base Directory.
> 
> Generally we are having OID in the Base Directory with a unique OID But 
> in my machine I found some object Id's with sequence like 
> 121193051,121193051.1 ....121193051.1200 and each file having the same 
> size (1GB) and same time.
> 
> By using the *pg_class* catalog, I tried to check those object names 
> with OID's but I'm unable to get any objects with those id's.
> 
> I applied Vacuum, Vacuum Full On that particular Database but the size 
> is still the same on these objects.
> 
> *My questions are,*
> 
> 1. Why object id's (OID) having like this 
> (121193051,121193051.1,121193051.2,121193051.3,121193051.4...........121193051.1200) with the same size?
> 2. Why are these oid's not having any objects ?
> 3. I think maybe  someone deleted/dropped these objects but why do these 
> objects occupy the same size even if I applied *Vacuum / vacuum full.?*


It all explained here:

https://www.postgresql.org/docs/current/storage-file-layout.html

In particular:


Caution

Note that while a table's filenode often matches its OID, this is not 
necessarily the case; some operations, like TRUNCATE, REINDEX, CLUSTER 
and some forms of ALTER TABLE, can change the filenode while preserving 
the OID. Avoid assuming that filenode and table OID are the same. Also, 
for certain system catalogs including pg_class itself, 
pg_class.relfilenode contains zero. The actual filenode number of these 
catalogs is stored in a lower-level data structure, and can be obtained 
using the pg_relation_filenode() function.


> *
> Here I'm attaching Document, please check for your reference.
> 
> 
> Thanks & Regards,
> Rajamohan Masa
> *
> *


-- 
Adrian Klaver
adrian.klaver@aklaver.com