files ending with .1 or .2

[Leonardo Francalanci]

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

[Arjen van der Meijden]

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

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Leonardo Francalanci]

> 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 ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

[Arjen van der Meijden]

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 ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Tom Lane]

Leonardo Francalanci <lf**********@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.

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Chris Browne]

lf**********@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.