{"Entry":{"collection":"storage","key":"fork-vm","name":"vm fork","aliases":[],"metadata":{"aliases":[],"category":"Relation forks","content_hash":"81541f39506de6e8f7ec102bb097e7d8e597eeeb7ec9db7657e8a3d807575178","imported_at":"2026-09-30T00:40:47.134958+08:00","name":"vm fork","name_zh":"","slug":"fork-vm","summary":"Each table and index is stored in a separate file. For ordinary relations, these files are named after the table or index's filenode number, which can be found in pg_class . relfilenode . But for temporary relations, the file name is of the form t BBB _ FFF , where BBB is the process number of the backend which created the file, and FFF is the filenode number. In either case, in addition to the main file (a/k/a main fork), each table and index has a free space map (see Section 66.3 ), which stores information about free space available in the relation. The free space map is stored in a file named with the filenode number plus the suffix _fsm . Tables also have a visibility map , stored in a fork with the suffix _vm , to track which pages are known to have no dead tuples. The visibility map is described further in Section 66.4 . Unlogged tables and indexes have a third fork, known as the initialization fork, which is stored in a fork with the suffix _init (see Section 66.5 )."}},"Definition":{"Collection":"storage","Key":"fork-vm","SourceDatabase":"center","Version":"18","SourceTable":"storage_structure","SourceKey":"fork-vm","SourceRevision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","Facts":{"comparison_data":{"fork":"vm"},"comparison_hash":"0f7e444c74befed2e9e038b208922f35c10a3caa1ec789947fda5dd19339d4d4","description":["Each table and index is stored in a separate file. For ordinary relations, these files are named after the table or index's filenode number, which can be found in pg_class . relfilenode . But for temporary relations, the file name is of the form t BBB _ FFF , where BBB is the process number of the backend which created the file, and FFF is the filenode number. In either case, in addition to the main file (a/k/a main fork), each table and index has a free space map (see Section 66.3 ), which stores information about free space available in the relation. The free space map is stored in a file named with the filenode number plus the suffix _fsm . Tables also have a visibility map , stored in a fork with the suffix _vm , to track which pages are known to have no dead tuples. The visibility map is described further in Section 66.4 . Unlogged tables and indexes have a third fork, known as the initialization fork, which is stored in a fork with the suffix _init (see Section 66.5 ).","When a table or index exceeds 1 GB, 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. This arrangement avoids problems on platforms that have file size limitations. (Actually, 1 GB is just the default segment size. The segment size can be adjusted using the configuration option --with-segsize when building PostgreSQL .) In principle, free space map and visibility map forks could require multiple segments as well, though this is unlikely to happen in practice."],"facts":[{"label":"Fork","value":"vm"}],"manual_html":"","manual_path":"/docs/18/storage-file-layout.html","related":[{"label":"Database file layout","url":"/wiki/storage/storage-file-layout/?v=18"}],"release":{"channel":"stable","label":"18.6","major":"18","ref":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2","revision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"},"sections":[],"signature":"","sources":[{"label":"PostgreSQL 18 English manual","path":"storage-file-layout.html","sha256":"8cdf46b5af669f41f0a77c2541863d63454ef8fbb44d22a75e576cf1a7efc9c9","url":"/docs/18/storage-file-layout.html"}],"tables":[]},"ManualEvidence":{"manual_path":"/docs/18/storage-file-layout.html","release":{"channel":"stable","label":"18.6","major":"18","ref":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2","revision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"},"sources":[{"label":"PostgreSQL 18 English manual","path":"storage-file-layout.html","sha256":"8cdf46b5af669f41f0a77c2541863d63454ef8fbb44d22a75e576cf1a7efc9c9","url":"/docs/18/storage-file-layout.html"}]},"MeasuredEvidence":{}},"Text":{"Collection":"storage","Key":"fork-vm","SourceDatabase":"center","Version":"18","Locale":"en","Title":"vm fork","Summary":"Each table and index is stored in a separate file. For ordinary relations, these files are named after the table or index's filenode number, which can be found in pg_class . relfilenode . But for temporary relations, the file name is of the form t BBB _ FFF , where BBB is the process number of the backend which created the file, and FFF is the filenode number. In either case, in addition to the main file (a/k/a main fork), each table and index has a free space map (see Section 66.3 ), which stores information about free space available in the relation. The free space map is stored in a file named with the filenode number plus the suffix _fsm . Tables also have a visibility map , stored in a fork with the suffix _vm , to track which pages are known to have no dead tuples. The visibility map is described further in Section 66.4 . Unlogged tables and indexes have a third fork, known as the initialization fork, which is stored in a fork with the suffix _init (see Section 66.5 ).\nWhen a table or index exceeds 1 GB, 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. This arrangement avoids problems on platforms that have file size limitations. (Actually, 1 GB is just the default segment size. The segment size can be adjusted using the configuration option --with-segsize when building PostgreSQL .) In principle, free space map and visibility map forks could require multiple segments as well, though this is unlikely to happen in practice.","BodyHTML":"\u003cp\u003eEach table and index is stored in a separate file. For ordinary relations, these files are named after the table or index\u0026#39;s filenode number, which can be found in pg_class . relfilenode . But for temporary relations, the file name is of the form t BBB _ FFF , where BBB is the process number of the backend which created the file, and FFF is the filenode number. In either case, in addition to the main file (a/k/a main fork), each table and index has a free space map (see Section 66.3 ), which stores information about free space available in the relation. The free space map is stored in a file named with the filenode number plus the suffix _fsm . Tables also have a visibility map , stored in a fork with the suffix _vm , to track which pages are known to have no dead tuples. The visibility map is described further in Section 66.4 . Unlogged tables and indexes have a third fork, known as the initialization fork, which is stored in a fork with the suffix _init (see Section 66.5 ).\nWhen a table or index exceeds 1 GB, it is divided into gigabyte-sized segments . The first segment\u0026#39;s file name is the same as the filenode; subsequent segments are named filenode.1, filenode.2, etc. This arrangement avoids problems on platforms that have file size limitations. (Actually, 1 GB is just the default segment size. The segment size can be adjusted using the configuration option --with-segsize when building PostgreSQL .) In principle, free space map and visibility map forks could require multiple segments as well, though this is unlikely to happen in practice.\u003c/p\u003e","SourceRevision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","ContentHash":"0a6c40cdb30fe4802013952bf67b4ec8a002a36ce3a03e5f854c6efd73313c4f","Payload":{"description":["Each table and index is stored in a separate file. For ordinary relations, these files are named after the table or index's filenode number, which can be found in pg_class . relfilenode . But for temporary relations, the file name is of the form t BBB _ FFF , where BBB is the process number of the backend which created the file, and FFF is the filenode number. In either case, in addition to the main file (a/k/a main fork), each table and index has a free space map (see Section 66.3 ), which stores information about free space available in the relation. The free space map is stored in a file named with the filenode number plus the suffix _fsm . Tables also have a visibility map , stored in a fork with the suffix _vm , to track which pages are known to have no dead tuples. The visibility map is described further in Section 66.4 . Unlogged tables and indexes have a third fork, known as the initialization fork, which is stored in a fork with the suffix _init (see Section 66.5 ).","When a table or index exceeds 1 GB, 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. This arrangement avoids problems on platforms that have file size limitations. (Actually, 1 GB is just the default segment size. The segment size can be adjusted using the configuration option --with-segsize when building PostgreSQL .) In principle, free space map and visibility map forks could require multiple segments as well, though this is unlikely to happen in practice."],"manual_html":"","related":[{"label":"Database file layout","url":"/wiki/storage/storage-file-layout/?v=18"}],"sections":[],"tables":[]}},"RequestedLocale":"zh-Hans","Fallback":true,"Versions":["10","11","12","13","14","15","16","17","18","19","20"],"Locales":["en"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}