2004-08-20 06:29:33 +02:00
<!--
2010-09-20 22:08:53 +02:00
doc/src/sgml/ref/alter_index.sgml
2004-08-20 06:29:33 +02:00
PostgreSQL documentation
-->
2017-10-20 03:16:39 +02:00
<refentry id="sql-alterindex">
2014-02-24 03:25:35 +01:00
<indexterm zone="sql-alterindex">
<primary>ALTER INDEX</primary>
</indexterm>
2004-08-20 06:29:33 +02:00
<refmeta>
2010-04-03 09:23:02 +02:00
<refentrytitle>ALTER INDEX</refentrytitle>
2008-11-14 11:22:48 +01:00
<manvolnum>7</manvolnum>
2004-08-20 06:29:33 +02:00
<refmiscinfo>SQL - Language Statements</refmiscinfo>
</refmeta>
<refnamediv>
<refname>ALTER INDEX</refname>
<refpurpose>change the definition of an index</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
2017-10-09 04:00:57 +02:00
ALTER INDEX [ IF EXISTS ] <replaceable class="parameter">name</replaceable> RENAME TO <replaceable class="parameter">new_name</replaceable>
ALTER INDEX [ IF EXISTS ] <replaceable class="parameter">name</replaceable> SET TABLESPACE <replaceable class="parameter">tablespace_name</replaceable>
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
ALTER INDEX <replaceable class="parameter">name</replaceable> ATTACH PARTITION <replaceable class="parameter">index_name</replaceable>
2021-02-13 08:06:11 +01:00
ALTER INDEX <replaceable class="parameter">name</replaceable> [ NO ] DEPENDS ON EXTENSION <replaceable class="parameter">extension_name</replaceable>
2020-06-30 18:26:51 +02:00
ALTER INDEX [ IF EXISTS ] <replaceable class="parameter">name</replaceable> SET ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] )
2017-10-09 04:00:57 +02:00
ALTER INDEX [ IF EXISTS ] <replaceable class="parameter">name</replaceable> RESET ( <replaceable class="parameter">storage_parameter</replaceable> [, ... ] )
ALTER INDEX [ IF EXISTS ] <replaceable class="parameter">name</replaceable> ALTER [ COLUMN ] <replaceable class="parameter">column_number</replaceable>
SET STATISTICS <replaceable class="parameter">integer</replaceable>
ALTER INDEX ALL IN TABLESPACE <replaceable class="parameter">name</replaceable> [ OWNED BY <replaceable class="parameter">role_name</replaceable> [, ... ] ]
SET TABLESPACE <replaceable class="parameter">new_tablespace</replaceable> [ NOWAIT ]
2004-08-20 06:29:33 +02:00
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>
<command>ALTER INDEX</command> changes the definition of an existing index.
2018-10-25 09:33:17 +02:00
There are several subforms described below. Note that the lock level required
may differ for each subform. An <literal>ACCESS EXCLUSIVE</literal> lock is held
unless explicitly noted. When multiple subcommands are listed, the lock
held will be the strictest one required from any subcommand.
2004-08-20 06:29:33 +02:00
<variablelist>
<varlistentry>
2005-08-22 21:40:37 +02:00
<term><literal>RENAME</literal></term>
2004-08-20 06:29:33 +02:00
<listitem>
<para>
2010-11-23 21:27:50 +01:00
The <literal>RENAME</literal> form changes the name of the index.
Fully enforce uniqueness of constraint names.
It's been true for a long time that we expect names of table and domain
constraints to be unique among the constraints of that table or domain.
However, the enforcement of that has been pretty haphazard, and it missed
some corner cases such as creating a CHECK constraint and then an index
constraint of the same name (as per recent report from André Hänsel).
Also, due to the lack of an actual unique index enforcing this, duplicates
could be created through race conditions.
Moreover, the code that searches pg_constraint has been quite inconsistent
about how to handle duplicate names if one did occur: some places checked
and threw errors if there was more than one match, while others just
processed the first match they came to.
To fix, create a unique index on (conrelid, contypid, conname). Since
either conrelid or contypid is zero, this will separately enforce
uniqueness of constraint names among constraints of any one table and any
one domain. (If we ever implement SQL assertions, and put them into this
catalog, more thought might be needed. But it'd be at least as reasonable
to put them into a new catalog; having overloaded this one catalog with
two kinds of constraints was a mistake already IMO.) This index can replace
the existing non-unique index on conrelid, though we need to keep the one
on contypid for query performance reasons.
Having done that, we can simplify the logic in various places that either
coped with duplicates or neglected to, as well as potentially improve
lookup performance when searching for a constraint by name.
Also, as per our usual practice, install a preliminary check so that you
get something more friendly than a unique-index violation report in the
case complained of by André. And teach ChooseIndexName to avoid choosing
autogenerated names that would draw such a failure.
While it's not possible to make such a change in the back branches,
it doesn't seem quite too late to put this into v11, so do so.
Discussion: https://postgr.es/m/0c1001d4428f$0942b430$1bc81c90$@webkr.de
2018-09-04 19:45:35 +02:00
If the index is associated with a table constraint (either
<literal>UNIQUE</literal>, <literal>PRIMARY KEY</literal>,
or <literal>EXCLUDE</literal>), the constraint is renamed as well.
2005-08-22 21:40:37 +02:00
There is no effect on the stored data.
2004-08-20 06:29:33 +02:00
</para>
2018-10-25 09:33:17 +02:00
<para>
Renaming an index acquires a <literal>SHARE UPDATE EXCLUSIVE</literal>
lock.
</para>
2004-08-20 06:29:33 +02:00
</listitem>
</varlistentry>
<varlistentry>
<term><literal>SET TABLESPACE</literal></term>
<listitem>
<para>
This form changes the index's tablespace to the specified tablespace and
moves the data file(s) associated with the index to the new tablespace.
2014-08-22 01:06:17 +02:00
To change the tablespace of an index, you must own the index and have
<literal>CREATE</literal> privilege on the new tablespace.
All indexes in the current database in a tablespace can be moved by using
the <literal>ALL IN TABLESPACE</literal> form, which will lock all
indexes to be moved and then move each one. This form also supports
<literal>OWNED BY</literal>, which will only move indexes owned by the
roles specified. If the <literal>NOWAIT</literal> option is specified
then the command will fail if it is unable to acquire all of the locks
required immediately. Note that system catalogs will not be moved by
this command, use <command>ALTER DATABASE</command> or explicit
<command>ALTER INDEX</command> invocations instead if desired.
2010-11-23 21:27:50 +01:00
See also
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
<link linkend="sql-createtablespace"><command>CREATE TABLESPACE</command></link>.
2004-08-20 06:29:33 +02:00
</para>
</listitem>
</varlistentry>
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
<varlistentry>
<term><literal>ATTACH PARTITION</literal></term>
<listitem>
<para>
Causes the named index to become attached to the altered index.
The named index must be on a partition of the table containing the
index being altered, and have an equivalent definition. An attached
index cannot be dropped by itself, and will automatically be dropped
if its parent index is dropped.
</para>
</listitem>
</varlistentry>
2016-04-05 23:38:54 +02:00
<varlistentry>
2020-04-20 19:42:12 +02:00
<term><literal>DEPENDS ON EXTENSION <replaceable class="parameter">extension_name</replaceable></literal></term>
<term><literal>NO DEPENDS ON EXTENSION <replaceable class="parameter">extension_name</replaceable></literal></term>
2016-04-05 23:38:54 +02:00
<listitem>
<para>
2020-04-20 19:42:12 +02:00
This form marks the index as dependent on the extension, or no longer
dependent on that extension if <literal>NO</literal> is specified.
An index that's marked as dependent on an extension is automatically
dropped when the extension is dropped.
2016-04-05 23:38:54 +02:00
</para>
</listitem>
</varlistentry>
2006-07-02 04:23:23 +02:00
<varlistentry>
2020-06-30 18:26:51 +02:00
<term><literal>SET ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] )</literal></term>
2006-07-02 04:23:23 +02:00
<listitem>
<para>
2006-07-04 20:07:24 +02:00
This form changes one or more index-method-specific storage parameters
for the index. See
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
<link linkend="sql-createindex"><command>CREATE INDEX</command></link>
2006-07-04 20:07:24 +02:00
for details on the available parameters. Note that the index contents
will not be modified immediately by this command; depending on the
Update reference documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
2007-02-01 00:26:05 +01:00
parameter you might need to rebuild the index with
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
<link linkend="sql-reindex"><command>REINDEX</command></link>
2006-07-04 20:07:24 +02:00
to get the desired effects.
2006-07-02 04:23:23 +02:00
</para>
</listitem>
</varlistentry>
<varlistentry>
2017-10-09 04:00:57 +02:00
<term><literal>RESET ( <replaceable class="parameter">storage_parameter</replaceable> [, ... ] )</literal></term>
2006-07-02 04:23:23 +02:00
<listitem>
<para>
2006-07-04 20:07:24 +02:00
This form resets one or more index-method-specific storage parameters to
2017-10-09 03:44:17 +02:00
their defaults. As with <literal>SET</literal>, a <literal>REINDEX</literal>
Update reference documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
2007-02-01 00:26:05 +01:00
might be needed to update the index entirely.
2006-07-02 04:23:23 +02:00
</para>
</listitem>
</varlistentry>
2017-09-06 22:46:01 +02:00
<varlistentry>
2017-10-09 04:00:57 +02:00
<term><literal>ALTER [ COLUMN ] <replaceable class="parameter">column_number</replaceable> SET STATISTICS <replaceable class="parameter">integer</replaceable></literal></term>
2017-09-06 22:46:01 +02:00
<listitem>
<para>
This form sets the per-column statistics-gathering target for
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
subsequent <link linkend="sql-analyze"><command>ANALYZE</command></link> operations, though can
2017-09-06 22:46:01 +02:00
be used only on index columns that are defined as an expression.
Since expressions lack a unique name, we refer to them using the
2018-05-21 20:49:53 +02:00
ordinal number of the index column.
2017-09-06 22:46:01 +02:00
The target can be set in the range 0 to 10000; alternatively, set it
to -1 to revert to using the system default statistics
2017-11-23 15:39:47 +01:00
target (<xref linkend="guc-default-statistics-target"/>).
2017-09-06 22:46:01 +02:00
For more information on the use of statistics by the
<productname>PostgreSQL</productname> query planner, refer to
2017-11-23 15:39:47 +01:00
<xref linkend="planner-stats"/>.
2017-09-06 22:46:01 +02:00
</para>
</listitem>
</varlistentry>
2004-08-20 06:29:33 +02:00
</variablelist>
</para>
</refsect1>
<refsect1>
<title>Parameters</title>
<variablelist>
2016-04-06 00:03:42 +02:00
<varlistentry>
<term><literal>IF EXISTS</literal></term>
<listitem>
<para>
Do not throw an error if the index does not exist. A notice is issued
in this case.
</para>
</listitem>
</varlistentry>
2017-09-06 22:46:01 +02:00
<varlistentry>
2017-10-09 04:00:57 +02:00
<term><replaceable class="parameter">column_number</replaceable></term>
2017-09-06 22:46:01 +02:00
<listitem>
<para>
The ordinal number refers to the ordinal (left-to-right) position
of the index column.
</para>
</listitem>
</varlistentry>
2004-08-20 06:29:33 +02:00
<varlistentry>
2017-10-09 04:00:57 +02:00
<term><replaceable class="parameter">name</replaceable></term>
2004-08-20 06:29:33 +02:00
<listitem>
<para>
2005-08-22 21:40:37 +02:00
The name (possibly schema-qualified) of an existing index to
alter.
2004-08-20 06:29:33 +02:00
</para>
</listitem>
</varlistentry>
<varlistentry>
2017-10-09 04:00:57 +02:00
<term><replaceable class="parameter">new_name</replaceable></term>
2004-08-20 06:29:33 +02:00
<listitem>
<para>
2007-05-15 21:13:55 +02:00
The new name for the index.
2004-08-20 06:29:33 +02:00
</para>
</listitem>
</varlistentry>
<varlistentry>
2017-10-09 04:00:57 +02:00
<term><replaceable class="parameter">tablespace_name</replaceable></term>
2004-08-20 06:29:33 +02:00
<listitem>
<para>
2005-08-22 21:40:37 +02:00
The tablespace to which the index will be moved.
2004-08-20 06:29:33 +02:00
</para>
</listitem>
</varlistentry>
2016-04-05 23:38:54 +02:00
<varlistentry>
2017-10-09 04:00:57 +02:00
<term><replaceable class="parameter">extension_name</replaceable></term>
2016-04-05 23:38:54 +02:00
<listitem>
<para>
The name of the extension that the index is to depend on.
</para>
</listitem>
</varlistentry>
2006-07-04 20:07:24 +02:00
<varlistentry>
2017-10-09 04:00:57 +02:00
<term><replaceable class="parameter">storage_parameter</replaceable></term>
2006-07-04 20:07:24 +02:00
<listitem>
<para>
The name of an index-method-specific storage parameter.
</para>
</listitem>
</varlistentry>
<varlistentry>
2017-10-09 04:00:57 +02:00
<term><replaceable class="parameter">value</replaceable></term>
2006-07-04 20:07:24 +02:00
<listitem>
<para>
The new value for an index-method-specific storage parameter.
This might be a number or a word depending on the parameter.
</para>
</listitem>
</varlistentry>
2004-08-20 06:29:33 +02:00
</variablelist>
</refsect1>
<refsect1>
<title>Notes</title>
<para>
2004-08-21 18:16:04 +02:00
These operations are also possible using
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
<link linkend="sql-altertable"><command>ALTER TABLE</command></link>.
2017-10-09 03:44:17 +02:00
<command>ALTER INDEX</command> is in fact just an alias for the forms
of <command>ALTER TABLE</command> that apply to indexes.
2004-08-20 06:29:33 +02:00
</para>
2005-08-22 21:40:37 +02:00
<para>
2017-10-09 03:44:17 +02:00
There was formerly an <command>ALTER INDEX OWNER</command> variant, but
2005-08-22 21:40:37 +02:00
this is now ignored (with a warning). An index cannot have an owner
different from its table's owner. Changing the table's owner
automatically changes the index as well.
</para>
2004-08-20 06:29:33 +02:00
<para>
Changing any part of a system catalog index is not permitted.
</para>
</refsect1>
<refsect1>
<title>Examples</title>
<para>
To rename an existing index:
<programlisting>
ALTER INDEX distributors RENAME TO suppliers;
</programlisting>
</para>
2010-11-23 21:27:50 +01:00
<para>
2005-08-22 21:40:37 +02:00
To move an index to a different tablespace:
2004-08-20 06:29:33 +02:00
<programlisting>
ALTER INDEX distributors SET TABLESPACE fasttablespace;
2006-07-04 20:07:24 +02:00
</programlisting>
</para>
2010-11-23 21:27:50 +01:00
<para>
2006-07-04 20:07:24 +02:00
To change an index's fill factor (assuming that the index method
supports it):
<programlisting>
ALTER INDEX distributors SET (fillfactor = 75);
REINDEX INDEX distributors;
2011-08-07 09:49:45 +02:00
</programlisting></para>
2004-08-20 06:29:33 +02:00
2017-09-06 22:46:01 +02:00
<para>
Set the statistics-gathering target for an expression index:
<programlisting>
CREATE INDEX coord_idx ON measured (x, y, (z + t));
ALTER INDEX coord_idx ALTER COLUMN 3 SET STATISTICS 1000;
2018-05-21 20:41:27 +02:00
</programlisting></para>
2017-09-06 22:46:01 +02:00
2004-08-20 06:29:33 +02:00
</refsect1>
<refsect1>
<title>Compatibility</title>
<para>
2017-10-09 03:44:17 +02:00
<command>ALTER INDEX</command> is a <productname>PostgreSQL</productname>
2004-08-24 02:06:51 +02:00
extension.
2004-08-20 06:29:33 +02:00
</para>
</refsect1>
2006-07-04 20:07:24 +02:00
<refsect1>
<title>See Also</title>
<simplelist type="inline">
2017-11-23 15:39:47 +01:00
<member><xref linkend="sql-createindex"/></member>
<member><xref linkend="sql-reindex"/></member>
2006-07-04 20:07:24 +02:00
</simplelist>
</refsect1>
2004-08-20 06:29:33 +02:00
</refentry>
