rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgresql/src/backend/storage/smgr/README

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

53 lines
2.5 KiB
Plaintext
Raw Normal View History

Remove cvs keywords from all files.
2010-09-20 22:08:53 +02:00
src/backend/storage/smgr/README
Make source code READMEs more consistent. Add CVS tags to all README files.
2008-03-20 18:55:15 +01:00
Improve code documentation about "magnetic disk" storage manager. The modern incarnation of md.c is by no means specific to magnetic disk technology, but every so often we hear from someone who's misled by the label. Try to clarify that it will work for anything that supports standard filesystem operations. Per suggestion from Andrew Dunstan.
2013-03-30 19:23:45 +01:00
Storage Managers
================
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
Restructure smgr API as per recent proposal. smgr no longer depends on the relcache, and so the notion of 'blind write' is gone. This should improve efficiency in bgwriter and background checkpoint processes. Internal restructuring in md.c to remove the not-very-useful array of MdfdVec objects --- might as well just use pointers. Also remove the long-dead 'persistent main memory' storage manager (mm.c), since it seems quite unlikely to ever get resurrected.
2004-02-10 02:55:27 +01:00
In the original Berkeley Postgres system, there were several storage managers,
of which only the "magnetic disk" manager remains. (At Berkeley there were
also managers for the Sony WORM optical disk jukebox and persistent main
memory, but these were never supported in any externally released Postgres,
Improve code documentation about "magnetic disk" storage manager. The modern incarnation of md.c is by no means specific to magnetic disk technology, but every so often we hear from someone who's misled by the label. Try to clarify that it will work for anything that supports standard filesystem operations. Per suggestion from Andrew Dunstan.
2013-03-30 19:23:45 +01:00
nor in any version of PostgreSQL.) The "magnetic disk" manager is itself
seriously misnamed, because actually it supports any kind of device for
which the operating system provides standard filesystem operations; which
these days is pretty much everything of interest. However, we retain the
notion of a storage manager switch in case anyone ever wants to reintroduce
other kinds of storage managers. Removing the switch layer would save
nothing noticeable anyway, since storage-access operations are surely far
more expensive than one extra layer of C function calls.
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
Restructure smgr API as per recent proposal. smgr no longer depends on the relcache, and so the notion of 'blind write' is gone. This should improve efficiency in bgwriter and background checkpoint processes. Internal restructuring in md.c to remove the not-very-useful array of MdfdVec objects --- might as well just use pointers. Also remove the long-dead 'persistent main memory' storage manager (mm.c), since it seems quite unlikely to ever get resurrected.
2004-02-10 02:55:27 +01:00
In Berkeley Postgres each relation was tagged with the ID of the storage
Improve code documentation about "magnetic disk" storage manager. The modern incarnation of md.c is by no means specific to magnetic disk technology, but every so often we hear from someone who's misled by the label. Try to clarify that it will work for anything that supports standard filesystem operations. Per suggestion from Andrew Dunstan.
2013-03-30 19:23:45 +01:00
manager to use for it. This is gone. It would be probably more reasonable
to associate storage managers with tablespaces, should we ever re-introduce
multiple storage managers into the system catalogs.
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
The files in this directory, and their contents, are
Improve code documentation about "magnetic disk" storage manager. The modern incarnation of md.c is by no means specific to magnetic disk technology, but every so often we hear from someone who's misled by the label. Try to clarify that it will work for anything that supports standard filesystem operations. Per suggestion from Andrew Dunstan.
2013-03-30 19:23:45 +01:00
smgr.c The storage manager switch dispatch code. The routines in
this file call the appropriate storage manager to do storage
accesses requested by higher-level code. smgr.c also manages
the file handle cache (SMgrRelation table).
md.c The "magnetic disk" storage manager, which is really just
an interface to the kernel's filesystem operations.
Restructure smgr API as per recent proposal. smgr no longer depends on the relcache, and so the notion of 'blind write' is gone. This should improve efficiency in bgwriter and background checkpoint processes. Internal restructuring in md.c to remove the not-very-useful array of MdfdVec objects --- might as well just use pointers. Also remove the long-dead 'persistent main memory' storage manager (mm.c), since it seems quite unlikely to ever get resurrected.
2004-02-10 02:55:27 +01:00
Note that md.c in turn relies on src/backend/storage/file/fd.c.
Introduce the concept of relation forks. An smgr relation can now consist of multiple forks, and each fork can be created and grown separately. The bulk of this patch is about changing the smgr API to include an extra ForkNumber argument in every smgr function. Also, smgrscheduleunlink and smgrdounlink no longer implicitly call smgrclose, because other forks might still exist after unlinking one. The callers of those functions have been modified to call smgrclose instead. This patch in itself doesn't have any user-visible effect, but provides the infrastructure needed for upcoming patches. The additional forks envisioned are a rewritten FSM implementation that doesn't rely on a fixed-size shared memory block, and a visibility map to allow skipping portions of a table in VACUUM that have no dead tuples.
2008-08-11 13:05:11 +02:00
Improve code documentation about "magnetic disk" storage manager. The modern incarnation of md.c is by no means specific to magnetic disk technology, but every so often we hear from someone who's misled by the label. Try to clarify that it will work for anything that supports standard filesystem operations. Per suggestion from Andrew Dunstan.
2013-03-30 19:23:45 +01:00
Introduce the concept of relation forks. An smgr relation can now consist of multiple forks, and each fork can be created and grown separately. The bulk of this patch is about changing the smgr API to include an extra ForkNumber argument in every smgr function. Also, smgrscheduleunlink and smgrdounlink no longer implicitly call smgrclose, because other forks might still exist after unlinking one. The callers of those functions have been modified to call smgrclose instead. This patch in itself doesn't have any user-visible effect, but provides the infrastructure needed for upcoming patches. The additional forks envisioned are a rewritten FSM implementation that doesn't rely on a fixed-size shared memory block, and a visibility map to allow skipping portions of a table in VACUUM that have no dead tuples.
2008-08-11 13:05:11 +02:00
Relation Forks
==============
Since 8.4, a single smgr relation can be comprised of multiple physical
files, called relation forks. This allows storing additional metadata like
Free Space information in additional forks, which can be grown and truncated
independently of the main data file, while still treating it all as a single
physical relation in system catalogs.
It is assumed that the main fork, fork number 0 or MAIN_FORKNUM, always
Fix obsolete statement in smgr/README. Since commit 2d00190495b22e0d0ba351b2cda9c95fb2e3d083, fork numbers are defined in relpath.h not relfilenode.h. Fabrízio de Royes Mello
2014-07-28 22:30:14 +02:00
exists. Fork numbers are assigned in src/include/common/relpath.h.
Introduce the concept of relation forks. An smgr relation can now consist of multiple forks, and each fork can be created and grown separately. The bulk of this patch is about changing the smgr API to include an extra ForkNumber argument in every smgr function. Also, smgrscheduleunlink and smgrdounlink no longer implicitly call smgrclose, because other forks might still exist after unlinking one. The callers of those functions have been modified to call smgrclose instead. This patch in itself doesn't have any user-visible effect, but provides the infrastructure needed for upcoming patches. The additional forks envisioned are a rewritten FSM implementation that doesn't rely on a fixed-size shared memory block, and a visibility map to allow skipping portions of a table in VACUUM that have no dead tuples.
2008-08-11 13:05:11 +02:00
Functions in smgr.c and md.c take an extra fork number argument, in addition
Change internal RelFileNode references to RelFileNumber or RelFileLocator. We have been using the term RelFileNode to refer to either (1) the integer that is used to name the sequence of files for a certain relation within the directory set aside for that tablespace/database combination; or (2) that value plus the OIDs of the tablespace and database; or occasionally (3) the whole series of files created for a relation based on those values. Using the same name for more than one thing is confusing. Replace RelFileNode with RelFileNumber when we're talking about just the single number, i.e. (1) from above, and with RelFileLocator when we're talking about all the things that are needed to locate a relation's files on disk, i.e. (2) from above. In the places where we refer to (3) as a relfilenode, instead refer to "relation storage". Since there is a ton of SQL code in the world that knows about pg_class.relfilenode, don't change the name of that column, or of other SQL-facing things that derive their name from it. On the other hand, do adjust closely-related internal terminology. For example, the structure member names dbNode and spcNode appear to be derived from the fact that the structure itself was called RelFileNode, so change those to dbOid and spcOid. Likewise, various variables with names like rnode and relnode get renamed appropriately, according to how they're being used in context. Hopefully, this is clearer than before. It is also preparation for future patches that intend to widen the relfilenumber fields from its current width of 32 bits. Variables that store a relfilenumber are now declared as type RelFileNumber rather than type Oid; right now, these are the same, but that can now more easily be changed. Dilip Kumar, per an idea from me. Reviewed also by Andres Freund. I fixed some whitespace issues, changed a couple of words in a comment, and made one other minor correction. Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 17:39:09 +02:00
to relfilelocator and block number, to identify which relation fork you want to
Introduce the concept of relation forks. An smgr relation can now consist of multiple forks, and each fork can be created and grown separately. The bulk of this patch is about changing the smgr API to include an extra ForkNumber argument in every smgr function. Also, smgrscheduleunlink and smgrdounlink no longer implicitly call smgrclose, because other forks might still exist after unlinking one. The callers of those functions have been modified to call smgrclose instead. This patch in itself doesn't have any user-visible effect, but provides the infrastructure needed for upcoming patches. The additional forks envisioned are a rewritten FSM implementation that doesn't rely on a fixed-size shared memory block, and a visibility map to allow skipping portions of a table in VACUUM that have no dead tuples.
2008-08-11 13:05:11 +02:00
access. Since most code wants to access the main fork, a shortcut version of
ReadBuffer that accesses MAIN_FORKNUM is provided in the buffer manager for
convenience.