Обсуждение: files ending with .1 or .2
I got a table with oid 25459. The file is 1073741824 bytes big. I did some more inserts, and now I have this two new files: size/name: 1073741824 25459.1 21053440 25459.2 What are they? The 25459.1 looks exactly like the 25459. I tried looking at the docs, but searching for ".1" or ".2" wasn't that helpful...
When a data file for a specific table (or index?) is larger than 1GB, its split up in several parts. This is probably a left over from the time OSs used to have problems with large files. The file name, that number, is the OID of the table afaik. And the postfix is of course the number in the order of parts. Best regards, Arjen On 20-10-2004 9:39, Leonardo Francalanci wrote: > I got a table with oid 25459. > The file is 1073741824 bytes big. > I did some more inserts, and now I have this two new files: > > size/name: > > 1073741824 25459.1 > 21053440 25459.2 > > > What are they? > The 25459.1 looks exactly like the 25459. > > I tried looking at the docs, but searching for ".1" or ".2" wasn't that > helpful... > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster >
> When a data file for a specific table (or index?) is larger than 1GB, > its split up in several parts. This is probably a left over from the > time OSs used to have problems with large files. Thank you. Is there any documentation I can read about this?
I don't know. I just deduced that from an earlier situation where I new the size of the data, and noticed that the largest table was split up in enough 1GB parts to fit that size ;) Best regards, Arjen On 20-10-2004 10:14, Leonardo Francalanci wrote: >> When a data file for a specific table (or index?) is larger than 1GB, >> its split up in several parts. This is probably a left over from the >> time OSs used to have problems with large files. > > > Thank you. > Is there any documentation I can read about this? > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
Leonardo Francalanci <lfrancalanci@simtel.ie> writes: > Is there any documentation I can read about this? The best concise documentation I know about is in the CVS-tip docs for contrib/oid2name (reproduced below; the bit about tablespaces is irrelevant to pre-8.0 versions, but the rest is accurate). I've been wanting to transpose this into the mainstream admin docs, but haven't decided where to put it. regards, tom lane Databases are placed in directories named after their OIDs in pg_database, and the table files within a database's directory are named by "filenode" numbers, which are stored in pg_class.relfilenode. 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. When a table exceeds 1Gb, it is divided into gigabyte-sized "segments". The first segment's file name is the same as the filenode; subsequent segments are named filenode.1, filenode.2, etc. Tablespaces make the scenario more complicated. Each non-default tablespace has a symlink inside the pg_tblspc directory, which points to the physical tablespace directory (as specified in its CREATE TABLESPACE command). The symlink is named after the tablespace's OID. Inside the physical tablespace directory there is another directory for each database that has elements in the tablespace, named after the database's OID. Tables within that directory follow the filenode naming scheme. The "pg_default" tablespace is not addressed via pg_tblspc, but corresponds to $PGDATA/base.
lfrancalanci@simtel.ie (Leonardo Francalanci) writes: >> When a data file for a specific table (or index?) is larger than >> 1GB, its split up in several parts. This is probably a left over >> from the time OSs used to have problems with large files. > > Thank you. > Is there any documentation I can read about this? It's discussed in the Douglas & Douglas book on PostgreSQL; I'm not sure where else it gets discussed... -- let name="cbbrowne" and tld="cbbrowne.com" in String.concat "@" [name;tld];; http://www.ntlug.org/~cbbrowne/linuxxian.html A VAX is virtually a computer, but not quite.