Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commitbbce291

Browse files
committed
Doc: discourage use of partial indexes for poor-man's-partitioning.
Creating a bunch of non-overlapping partial indexes is generallya bad idea, so add an example saying not to do that.Back-patch to v10. Before that, the alternative of using (real)partitioning wasn't available, so that the tradeoff isn't quiteso clear cut.Discussion:https://postgr.es/m/CAKVFrvFY-f7kgwMRMiPLbPYMmgjc8Y2jjUGK_Y0HVcYAmU6ymg@mail.gmail.com
1 parentc987c9d commitbbce291

File tree

1 file changed

+46
-2
lines changed

1 file changed

+46
-2
lines changed

‎doc/src/sgml/indices.sgml

Lines changed: 46 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -975,10 +975,54 @@ CREATE UNIQUE INDEX tests_target_one_null ON tests ((target IS NULL)) WHERE targ
975975
know at least as much as the query planner knows, in particular you
976976
know when an index might be profitable. Forming this knowledge
977977
requires experience and understanding of how indexes in
978-
<productname>PostgreSQL</productname> work. In most cases, the advantage of a
979-
partial index over a regular index will be minimal.
978+
<productname>PostgreSQL</productname> work. In most cases, the
979+
advantage of a partial index over a regular index will be minimal.
980+
There are cases where they are quite counterproductive, as in <xref
981+
linkend="indexes-partial-ex4"/>.
980982
</para>
981983

984+
<example id="indexes-partial-ex4">
985+
<title>Do Not Use Partial Indexes as a Substitute for Partitioning</title>
986+
987+
<para>
988+
You might be tempted to create a large set of non-overlapping partial
989+
indexes, for example
990+
991+
<programlisting>
992+
CREATE INDEX mytable_cat_1 ON mytable (data) WHERE category = 1;
993+
CREATE INDEX mytable_cat_2 ON mytable (data) WHERE category = 2;
994+
CREATE INDEX mytable_cat_3 ON mytable (data) WHERE category = 3;
995+
...
996+
CREATE INDEX mytable_cat_<replaceable>N</replaceable> ON mytable (data) WHERE category = <replaceable>N</replaceable>;
997+
</programlisting>
998+
999+
This is a bad idea! Almost certainly, you'll be better off with a
1000+
single non-partial index, declared like
1001+
1002+
<programlisting>
1003+
CREATE INDEX mytable_cat_data ON mytable (category, data);
1004+
</programlisting>
1005+
1006+
(Put the category column first, for the reasons described in
1007+
<xref linkend="indexes-multicolumn"/>.) While a search in this larger
1008+
index might have to descend through a couple more tree levels than a
1009+
search in a smaller index, that's almost certainly going to be cheaper
1010+
than the planner effort needed to select the appropriate one of the
1011+
partial indexes. The core of the problem is that the system does not
1012+
understand the relationship among the partial indexes, and will
1013+
laboriously test each one to see if it's applicable to the current
1014+
query.
1015+
</para>
1016+
1017+
<para>
1018+
If your table is large enough that a single index really is a bad idea,
1019+
you should look into using partitioning instead (see
1020+
<xref linkend="ddl-partitioning"/>). With that mechanism, the system
1021+
does understand that the tables and indexes are non-overlapping, so
1022+
far better performance is possible.
1023+
</para>
1024+
</example>
1025+
9821026
<para>
9831027
More information about partial indexes can be found in <xref
9841028
linkend="ston89b"/>, <xref linkend="olson93"/>, and <xref

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp