[PATCH] Add section headings to index types doc - Mailing list pgsql-hackers
From | ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) |
---|---|
Subject | [PATCH] Add section headings to index types doc |
Date | |
Msg-id | 877dukhvzg.fsf@wibble.ilmari.org Whole thread Raw |
Responses |
Re: [PATCH] Add section headings to index types doc
|
List | pgsql-hackers |
Hi hackers, Every time I have to look up what kinds of operations each index type is suitable for, I get annoyed by the index types page being virtually unskimmable due to not having headings for each index type. Attached is a patch that adds <sect2> tags for each index type to make it easier to see where the description of each one starts. - ilmari -- "The surreality of the universe tends towards a maximum" -- Skud's Law "Never formulate a law or axiom that you're not prepared to live with the consequences of." -- Skud's Meta-Law From 57d9550b9286e7f6298763bb51d45393aa2eab4e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dagfinn=20Ilmari=20Manns=C3=A5ker?= <ilmari@ilmari.org> Date: Fri, 31 Jul 2020 10:20:48 +0100 Subject: [PATCH] Add section headers to index types doc This makes it easier to compare the properties of different index types at a glance. --- doc/src/sgml/indices.sgml | 460 ++++++++++++++++++++------------------ 1 file changed, 242 insertions(+), 218 deletions(-) diff --git a/doc/src/sgml/indices.sgml b/doc/src/sgml/indices.sgml index 28adaba72d..332d161547 100644 --- a/doc/src/sgml/indices.sgml +++ b/doc/src/sgml/indices.sgml @@ -122,244 +122,268 @@ B-tree indexes, which fit the most common situations. </para> - <para> - <indexterm> - <primary>index</primary> - <secondary>B-tree</secondary> - </indexterm> - <indexterm> - <primary>B-tree</primary> - <see>index</see> - </indexterm> - B-trees can handle equality and range queries on data that can be sorted - into some ordering. - In particular, the <productname>PostgreSQL</productname> query planner - will consider using a B-tree index whenever an indexed column is - involved in a comparison using one of these operators: + <sect2 id="indexes-types-btree"> + <title>B-tree</title> - <simplelist> - <member><literal><</literal></member> - <member><literal><=</literal></member> - <member><literal>=</literal></member> - <member><literal>>=</literal></member> - <member><literal>></literal></member> - </simplelist> + <para> + <indexterm> + <primary>index</primary> + <secondary>B-tree</secondary> + </indexterm> + <indexterm> + <primary>B-tree</primary> + <see>index</see> + </indexterm> + B-trees can handle equality and range queries on data that can be sorted + into some ordering. + In particular, the <productname>PostgreSQL</productname> query planner + will consider using a B-tree index whenever an indexed column is + involved in a comparison using one of these operators: - Constructs equivalent to combinations of these operators, such as - <literal>BETWEEN</literal> and <literal>IN</literal>, can also be implemented with - a B-tree index search. Also, an <literal>IS NULL</literal> or <literal>IS NOT - NULL</literal> condition on an index column can be used with a B-tree index. - </para> + <simplelist> + <member><literal><</literal></member> + <member><literal><=</literal></member> + <member><literal>=</literal></member> + <member><literal>>=</literal></member> + <member><literal>></literal></member> + </simplelist> - <para> - The optimizer can also use a B-tree index for queries involving the - pattern matching operators <literal>LIKE</literal> and <literal>~</literal> - <emphasis>if</emphasis> the pattern is a constant and is anchored to - the beginning of the string — for example, <literal>col LIKE - 'foo%'</literal> or <literal>col ~ '^foo'</literal>, but not - <literal>col LIKE '%bar'</literal>. However, if your database does not - use the C locale you will need to create the index with a special - operator class to support indexing of pattern-matching queries; see - <xref linkend="indexes-opclass"/> below. It is also possible to use - B-tree indexes for <literal>ILIKE</literal> and - <literal>~*</literal>, but only if the pattern starts with - non-alphabetic characters, i.e., characters that are not affected by - upper/lower case conversion. - </para> + Constructs equivalent to combinations of these operators, such as + <literal>BETWEEN</literal> and <literal>IN</literal>, can also be implemented with + a B-tree index search. Also, an <literal>IS NULL</literal> or <literal>IS NOT + NULL</literal> condition on an index column can be used with a B-tree index. + </para> - <para> - B-tree indexes can also be used to retrieve data in sorted order. - This is not always faster than a simple scan and sort, but it is - often helpful. - </para> + <para> + The optimizer can also use a B-tree index for queries involving the + pattern matching operators <literal>LIKE</literal> and <literal>~</literal> + <emphasis>if</emphasis> the pattern is a constant and is anchored to + the beginning of the string — for example, <literal>col LIKE + 'foo%'</literal> or <literal>col ~ '^foo'</literal>, but not + <literal>col LIKE '%bar'</literal>. However, if your database does not + use the C locale you will need to create the index with a special + operator class to support indexing of pattern-matching queries; see + <xref linkend="indexes-opclass"/> below. It is also possible to use + B-tree indexes for <literal>ILIKE</literal> and + <literal>~*</literal>, but only if the pattern starts with + non-alphabetic characters, i.e., characters that are not affected by + upper/lower case conversion. + </para> - <para> - <indexterm> - <primary>index</primary> - <secondary>hash</secondary> - </indexterm> - <indexterm> - <primary>hash</primary> - <see>index</see> - </indexterm> - Hash indexes can only handle simple equality comparisons. - The query planner will consider using a hash index whenever an - indexed column is involved in a comparison using the - <literal>=</literal> operator. - The following command is used to create a hash index: -<synopsis> -CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable> USING HASH (<replaceable>column</replaceable>); -</synopsis> - </para> + <para> + B-tree indexes can also be used to retrieve data in sorted order. + This is not always faster than a simple scan and sort, but it is + often helpful. + </para> + </sect2> - <para> - <indexterm> - <primary>index</primary> - <secondary>GiST</secondary> - </indexterm> - <indexterm> - <primary>GiST</primary> - <see>index</see> - </indexterm> - GiST indexes are not a single kind of index, but rather an infrastructure - within which many different indexing strategies can be implemented. - Accordingly, the particular operators with which a GiST index can be - used vary depending on the indexing strategy (the <firstterm>operator - class</firstterm>). As an example, the standard distribution of - <productname>PostgreSQL</productname> includes GiST operator classes - for several two-dimensional geometric data types, which support indexed - queries using these operators: + <sect2 id="indexes-types-hash"> + <title>Hash</title> - <simplelist> - <member><literal><<</literal></member> - <member><literal>&<</literal></member> - <member><literal>&></literal></member> - <member><literal>>></literal></member> - <member><literal><<|</literal></member> - <member><literal>&<|</literal></member> - <member><literal>|&></literal></member> - <member><literal>|>></literal></member> - <member><literal>@></literal></member> - <member><literal><@</literal></member> - <member><literal>~=</literal></member> - <member><literal>&&</literal></member> - </simplelist> + <para> + <indexterm> + <primary>index</primary> + <secondary>hash</secondary> + </indexterm> + <indexterm> + <primary>hash</primary> + <see>index</see> + </indexterm> + Hash indexes can only handle simple equality comparisons. + The query planner will consider using a hash index whenever an + indexed column is involved in a comparison using the + <literal>=</literal> operator. + The following command is used to create a hash index: + <synopsis> + CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable> USING HASH (<replaceable>column</replaceable>); + </synopsis> + </para> + </sect2> - (See <xref linkend="functions-geometry"/> for the meaning of - these operators.) - The GiST operator classes included in the standard distribution are - documented in <xref linkend="gist-builtin-opclasses-table"/>. - Many other GiST operator - classes are available in the <literal>contrib</literal> collection or as separate - projects. For more information see <xref linkend="gist"/>. - </para> + <sect2 id="indexes-type-gist"> + <title>GiST</title> - <para> - GiST indexes are also capable of optimizing <quote>nearest-neighbor</quote> - searches, such as -<programlisting><![CDATA[ -SELECT * FROM places ORDER BY location <-> point '(101,456)' LIMIT 10; -]]> -</programlisting> - which finds the ten places closest to a given target point. The ability - to do this is again dependent on the particular operator class being used. - In <xref linkend="gist-builtin-opclasses-table"/>, operators that can be - used in this way are listed in the column <quote>Ordering Operators</quote>. - </para> + <para> + <indexterm> + <primary>index</primary> + <secondary>GiST</secondary> + </indexterm> + <indexterm> + <primary>GiST</primary> + <see>index</see> + </indexterm> + GiST indexes are not a single kind of index, but rather an infrastructure + within which many different indexing strategies can be implemented. + Accordingly, the particular operators with which a GiST index can be + used vary depending on the indexing strategy (the <firstterm>operator + class</firstterm>). As an example, the standard distribution of + <productname>PostgreSQL</productname> includes GiST operator classes + for several two-dimensional geometric data types, which support indexed + queries using these operators: - <para> - <indexterm> - <primary>index</primary> - <secondary>SP-GiST</secondary> - </indexterm> - <indexterm> - <primary>SP-GiST</primary> - <see>index</see> - </indexterm> - SP-GiST indexes, like GiST indexes, offer an infrastructure that supports - various kinds of searches. SP-GiST permits implementation of a wide range - of different non-balanced disk-based data structures, such as quadtrees, - k-d trees, and radix trees (tries). As an example, the standard distribution of - <productname>PostgreSQL</productname> includes SP-GiST operator classes - for two-dimensional points, which support indexed - queries using these operators: + <simplelist> + <member><literal><<</literal></member> + <member><literal>&<</literal></member> + <member><literal>&></literal></member> + <member><literal>>></literal></member> + <member><literal><<|</literal></member> + <member><literal>&<|</literal></member> + <member><literal>|&></literal></member> + <member><literal>|>></literal></member> + <member><literal>@></literal></member> + <member><literal><@</literal></member> + <member><literal>~=</literal></member> + <member><literal>&&</literal></member> + </simplelist> - <simplelist> - <member><literal><<</literal></member> - <member><literal>>></literal></member> - <member><literal>~=</literal></member> - <member><literal><@</literal></member> - <member><literal><^</literal></member> - <member><literal>>^</literal></member> - </simplelist> + (See <xref linkend="functions-geometry"/> for the meaning of + these operators.) + The GiST operator classes included in the standard distribution are + documented in <xref linkend="gist-builtin-opclasses-table"/>. + Many other GiST operator + classes are available in the <literal>contrib</literal> collection or as separate + projects. For more information see <xref linkend="gist"/>. + </para> - (See <xref linkend="functions-geometry"/> for the meaning of - these operators.) - The SP-GiST operator classes included in the standard distribution are - documented in <xref linkend="spgist-builtin-opclasses-table"/>. - For more information see <xref linkend="spgist"/>. - </para> + <para> + GiST indexes are also capable of optimizing <quote>nearest-neighbor</quote> + searches, such as + <programlisting><![CDATA[ + SELECT * FROM places ORDER BY location <-> point '(101,456)' LIMIT 10; + ]]> + </programlisting> + which finds the ten places closest to a given target point. The ability + to do this is again dependent on the particular operator class being used. + In <xref linkend="gist-builtin-opclasses-table"/>, operators that can be + used in this way are listed in the column <quote>Ordering Operators</quote>. + </para> + </sect2> - <para> - Like GiST, SP-GiST supports <quote>nearest-neighbor</quote> searches. - For SP-GiST operator classes that support distance ordering, the - corresponding operator is specified in the <quote>Ordering Operators</quote> - column in <xref linkend="spgist-builtin-opclasses-table"/>. - </para> + <sect2 id="indexes-type-spgist"> + <title>SP-GiST</title> - <para> - <indexterm> - <primary>index</primary> - <secondary>GIN</secondary> - </indexterm> - <indexterm> - <primary>GIN</primary> - <see>index</see> - </indexterm> - GIN indexes are <quote>inverted indexes</quote> which are appropriate for - data values that contain multiple component values, such as arrays. An - inverted index contains a separate entry for each component value, and - can efficiently handle queries that test for the presence of specific - component values. - </para> + <para> + <indexterm> + <primary>index</primary> + <secondary>SP-GiST</secondary> + </indexterm> + <indexterm> + <primary>SP-GiST</primary> + <see>index</see> + </indexterm> + SP-GiST indexes, like GiST indexes, offer an infrastructure that supports + various kinds of searches. SP-GiST permits implementation of a wide range + of different non-balanced disk-based data structures, such as quadtrees, + k-d trees, and radix trees (tries). As an example, the standard distribution of + <productname>PostgreSQL</productname> includes SP-GiST operator classes + for two-dimensional points, which support indexed + queries using these operators: - <para> - Like GiST and SP-GiST, GIN can support - many different user-defined indexing strategies, and the particular - operators with which a GIN index can be used vary depending on the - indexing strategy. - As an example, the standard distribution of - <productname>PostgreSQL</productname> includes a GIN operator class - for arrays, which supports indexed queries using these operators: + <simplelist> + <member><literal><<</literal></member> + <member><literal>>></literal></member> + <member><literal>~=</literal></member> + <member><literal><@</literal></member> + <member><literal><^</literal></member> + <member><literal>>^</literal></member> + </simplelist> - <simplelist> - <member><literal><@</literal></member> - <member><literal>@></literal></member> - <member><literal>=</literal></member> - <member><literal>&&</literal></member> - </simplelist> + (See <xref linkend="functions-geometry"/> for the meaning of + these operators.) + The SP-GiST operator classes included in the standard distribution are + documented in <xref linkend="spgist-builtin-opclasses-table"/>. + For more information see <xref linkend="spgist"/>. + </para> - (See <xref linkend="functions-array"/> for the meaning of - these operators.) - The GIN operator classes included in the standard distribution are - documented in <xref linkend="gin-builtin-opclasses-table"/>. - Many other GIN operator - classes are available in the <literal>contrib</literal> collection or as separate - projects. For more information see <xref linkend="gin"/>. - </para> + <para> + Like GiST, SP-GiST supports <quote>nearest-neighbor</quote> searches. + For SP-GiST operator classes that support distance ordering, the + corresponding operator is specified in the <quote>Ordering Operators</quote> + column in <xref linkend="spgist-builtin-opclasses-table"/>. + </para> + </sect2> - <para> - <indexterm> - <primary>index</primary> - <secondary>BRIN</secondary> - </indexterm> - <indexterm> - <primary>BRIN</primary> - <see>index</see> - </indexterm> - BRIN indexes (a shorthand for Block Range INdexes) store summaries about - the values stored in consecutive physical block ranges of a table. - Like GiST, SP-GiST and GIN, - BRIN can support many different indexing strategies, - and the particular operators with which a BRIN index can be used - vary depending on the indexing strategy. - For data types that have a linear sort order, the indexed data - corresponds to the minimum and maximum values of the - values in the column for each block range. This supports indexed queries - using these operators: + <sect2 id="indexes-types-gin"> + <title>GIN</title> - <simplelist> - <member><literal><</literal></member> - <member><literal><=</literal></member> - <member><literal>=</literal></member> - <member><literal>>=</literal></member> - <member><literal>></literal></member> - </simplelist> + <para> + <indexterm> + <primary>index</primary> + <secondary>GIN</secondary> + </indexterm> + <indexterm> + <primary>GIN</primary> + <see>index</see> + </indexterm> + GIN indexes are <quote>inverted indexes</quote> which are appropriate for + data values that contain multiple component values, such as arrays. An + inverted index contains a separate entry for each component value, and + can efficiently handle queries that test for the presence of specific + component values. + </para> - The BRIN operator classes included in the standard distribution are - documented in <xref linkend="brin-builtin-opclasses-table"/>. - For more information see <xref linkend="brin"/>. - </para> + <para> + Like GiST and SP-GiST, GIN can support + many different user-defined indexing strategies, and the particular + operators with which a GIN index can be used vary depending on the + indexing strategy. + As an example, the standard distribution of + <productname>PostgreSQL</productname> includes a GIN operator class + for arrays, which supports indexed queries using these operators: + + <simplelist> + <member><literal><@</literal></member> + <member><literal>@></literal></member> + <member><literal>=</literal></member> + <member><literal>&&</literal></member> + </simplelist> + + (See <xref linkend="functions-array"/> for the meaning of + these operators.) + The GIN operator classes included in the standard distribution are + documented in <xref linkend="gin-builtin-opclasses-table"/>. + Many other GIN operator + classes are available in the <literal>contrib</literal> collection or as separate + projects. For more information see <xref linkend="gin"/>. + </para> + </sect2> + + <sect2 id="indexes-types-brin"> + <title>BRIN</title> + + <para> + <indexterm> + <primary>index</primary> + <secondary>BRIN</secondary> + </indexterm> + <indexterm> + <primary>BRIN</primary> + <see>index</see> + </indexterm> + BRIN indexes (a shorthand for Block Range INdexes) store summaries about + the values stored in consecutive physical block ranges of a table. + Like GiST, SP-GiST and GIN, + BRIN can support many different indexing strategies, + and the particular operators with which a BRIN index can be used + vary depending on the indexing strategy. + For data types that have a linear sort order, the indexed data + corresponds to the minimum and maximum values of the + values in the column for each block range. This supports indexed queries + using these operators: + + <simplelist> + <member><literal><</literal></member> + <member><literal><=</literal></member> + <member><literal>=</literal></member> + <member><literal>>=</literal></member> + <member><literal>></literal></member> + </simplelist> + + The BRIN operator classes included in the standard distribution are + documented in <xref linkend="brin-builtin-opclasses-table"/>. + For more information see <xref linkend="brin"/>. + </para> + </sect2> </sect1> -- 2.27.0
pgsql-hackers by date: