From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Erik Rijkers <er(at)xs4all(dot)nl>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Jürgen Purtz <juergen(at)purtz(dot)de>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Roger Harkavy <rogerharkavy(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Michael Paquier <michael(at)paquier(dot)xyz> |
Subject: | Re: Add A Glossary |
Date: | 2020-05-15 01:03:04 |
Message-ID: | 20200515010304.GN18456@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-hackers |
On Thu, May 14, 2020 at 08:00:17PM -0400, Alvaro Herrera wrote:
> + <glossterm>ACID</glossterm>
> + <glossdef>
> + <para>
> + <glossterm linkend="glossary-atomicity">Atomicity</glossterm>,
> + <glossterm linkend="glossary-consistency">consistency</glossterm>,
> + <glossterm linkend="glossary-isolation">isolation</glossterm>, and
> + <glossterm linkend="glossary-durability">durability</glossterm>.
> + A set of properties of database transactions intended to guarantee validity
> + in concurrent operation and even in event of errors, power failures, etc.
I would capitalize Consistency, Isolation, Durability, and say "These four
properties" or "This set of four properties" (althought that makes this sounds
more like a fun game of DBA jeopardy).
> + <glossterm>Background writer (process)</glossterm>
> <glossdef>
> <para>
> - A process that continuously writes dirty pages from
> + A process that continuously writes dirty
I don't like "continuously"
> + <glossterm linkend="glossary-data-page">data pages</glossterm> from
>
> + <glossentry id="glossary-bloat">
> + <glossterm>Bloat</glossterm>
> + <glossdef>
> + <para>
> + Space in data pages which does not contain relevant data,
> + such as unused (free) space or outdated row versions.
"current row versions" instead of relevant ?
> + <glossentry id="glossary-data-page">
> + <glossterm>Data page</glossterm>
> + <glossdef>
> + <para>
> + The basic structure used to store relation data.
> + All pages are of the same size.
> + Data pages are typically stored on disk, each in a specific file,
> + and can be read to <glossterm linkend="glossary-shared-memory">shared buffers</glossterm>
> + where they can be modified, becoming
> + <firstterm>dirty</firstterm>. They get clean by being written down
say "They become clean when written to disk"
> + to disk. New pages, which initially exist in memory only, are also
> + dirty until written.
> + <glossentry id="glossary-fork">
> + <glossterm>Fork</glossterm>
> + <glossdef>
> + <para>
> + Each of the separate segmented file sets that a relation stores its
> + data in. There exist a <firstterm>main fork</firstterm> and two secondary
"in which a relation's data is stored"
> + forks: the <glossterm linkend="glossary-fsm">free space map</glossterm>
> + <glossterm linkend="glossary-vm">visibility map</glossterm>.
missing "and" ?
> + <glossentry id="glossary-fsm">
> + <glossterm>Free space map (fork)</glossterm>
> + <glossdef>
> + <para>
> + A storage structure that keeps metadata about each data page in a table's
> + main storage space.
s/in/of/
just say "main fork"?
> The free space map entry for each space stores the
for each page ?
> + amount of free space that's available for future tuples, and is structured
> + so it is efficient to search for available space for a new tuple of a given
> + size.
..to be efficiently searched to find free space..
> The heap is realized within
> - <glossterm linkend="glossary-file-segment">segment files</glossterm>.
> + <glossterm linkend="glossary-file-segment">segmented files</glossterm>
> + in the relation's <glossterm linkend="glossary-fork">main fork</glossterm>.
Hm, the files aren't segmented. Say "one or more file segments per relation"
> + There also exist local objects that do not belong to schemas; some examples are
> + <glossterm linkend="glossary-extension">extensions</glossterm>,
> + <glossterm linkend="glossary-cast">data type casts</glossterm>, and
> + <glossterm linkend="glossary-foreign-data-wrapper">foreign data wrappers</glossterm>.
Don't extensions have schemas ?
> + <glossentry id="glossary-xid">
> + <glossterm>Transaction ID</glossterm>
> + <glossdef>
> + <para>
> + The numerical, unique, sequentially-assigned identifier that each
> + transaction receives when it first causes a database modification.
> + Frequently abbreviated <firstterm>xid</firstterm>.
abbreviated *as* xid
> + approximately four billion write transactions IDs can be generated;
> + to permit the system to run for longer than that would allow,
remove "would allow"
> <para>
> The process of removing outdated <glossterm linkend="glossary-tuple">tuple
> versions</glossterm> from tables, and other closely related
actually tables or materialized views..
> + <glossentry id="glossary-vm">
> + <glossterm>Visibility map (fork)</glossterm>
> + <glossdef>
> + <para>
> + A storage structure that keeps metadata about each data page
> + in a table's main storage space. The visibility map entry for
s/in/of/
main fork?
--
Justin
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-05-15 01:58:23 | Re: TLS docs fixes for <programlisting> |
Previous Message | Alvaro Herrera | 2020-05-15 00:00:17 | Re: Add A Glossary |
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2020-05-15 02:19:29 | Re: Transactions involving multiple postgres foreign servers, take 2 |
Previous Message | Atsushi Torikoshi | 2020-05-15 00:50:41 | Re: Add explanations which are influenced by track_io_timing |