diff options
| author | Amit Kapila <akapila@postgresql.org> | 2019-02-04 07:49:15 +0530 |
|---|---|---|
| committer | Amit Kapila <akapila@postgresql.org> | 2019-02-04 07:49:15 +0530 |
| commit | b0eaa4c51bbff3e3c600b11e5d104d6feb9ca77f (patch) | |
| tree | fcb1465d0d691fd9271414b03d53166e4e931132 /doc/src | |
| parent | be12aa47e60c45f331e91693efdbc94497d4e9b0 (diff) | |
| download | postgresql-b0eaa4c51bbff3e3c600b11e5d104d6feb9ca77f.tar.gz postgresql-b0eaa4c51bbff3e3c600b11e5d104d6feb9ca77f.zip | |
Avoid creation of the free space map for small heap relations, take 2.
Previously, all heaps had FSMs. For very small tables, this means that the
FSM took up more space than the heap did. This is wasteful, so now we
refrain from creating the FSM for heaps with 4 pages or fewer. If the last
known target block has insufficient space, we still try to insert into some
other page before giving up and extending the relation, since doing
otherwise leads to table bloat. Testing showed that trying every page
penalized performance slightly, so we compromise and try every other page.
This way, we visit at most two pages. Any pages with wasted free space
become visible at next relation extension, so we still control table bloat.
As a bonus, directly attempting one or two pages can even be faster than
consulting the FSM would have been.
Once the FSM is created for a heap we don't remove it even if somebody
deletes all the rows from the corresponding relation. We don't think it is
a useful optimization as it is quite likely that relation will again grow
to the same size.
Author: John Naylor, Amit Kapila
Reviewed-by: Amit Kapila
Tested-by: Mithun C Y
Discussion: https://www.postgresql.org/message-id/CAJVSVGWvB13PzpbLEecFuGFc5V2fsO736BsdTakPiPAcdMM5tQ@mail.gmail.com
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/sgml/storage.sgml | 13 |
1 files changed, 7 insertions, 6 deletions
diff --git a/doc/src/sgml/storage.sgml b/doc/src/sgml/storage.sgml index 8ef2ac80106..cbdad0c3fb5 100644 --- a/doc/src/sgml/storage.sgml +++ b/doc/src/sgml/storage.sgml @@ -590,12 +590,13 @@ tuple would otherwise be too big. <indexterm><primary>FSM</primary><see>Free Space Map</see></indexterm> <para> -Each heap and index relation, except for hash indexes, has a Free Space Map -(FSM) to keep track of available space in the relation. It's stored -alongside the main relation data in a separate relation fork, named after the -filenode number of the relation, plus a <literal>_fsm</literal> suffix. For example, -if the filenode of a relation is 12345, the FSM is stored in a file called -<filename>12345_fsm</filename>, in the same directory as the main relation file. +Each heap relation, unless it is very small, and each index relation, except +for hash indexes, has a Free Space Map (FSM) to keep track of available +space in the relation. It's stored alongside the main relation data in a +separate relation fork, named after the filenode number of the relation, plus +a <literal>_fsm</literal> suffix. For example, if the filenode of a relation +is 12345, the FSM is stored in a file called <filename>12345_fsm</filename>, +in the same directory as the main relation file. </para> <para> |