</programlisting>

is compared to the total number of tuples inserted, updated, or deleted

since the last <command>ANALYZE</command>.

For partitioned tables, inserts, updates and deletes on partitions

are counted towards this threshold; however, DDL

operations such as <literal>ATTACH</literal>, <literal>DETACH</literal>

and <literal>DROP</literal> are not, so running a manual

<command>ANALYZE</command> is recommended if the partition added or

removed contains a statistically significant volume of data.

</para>

<para>

<para>

Whenever you have significantly altered the distribution of data

within a table, running <link linkend="sql-analyze"><command>ANALYZE</command></link> is strongly recommended. This

includes bulk loading large amounts of data into the table as well as

attaching, detaching or dropping partitions. Running

includes bulk loading large amounts of data into the table. Running

<command>ANALYZE</command> (or <command>VACUUM ANALYZE</command>)

ensures that the planner has up-to-date statistics about the

table. With no statistics or obsolete statistics, the planner might

</para>

<para>

If the table being analyzed is partitioned, <command>ANALYZE</command>

will gather statistics by sampling blocks randomly from its partitions;

in addition, it will recurse into each partition and update its statistics.

(However, in multi-level partitioning scenarios, each leaf partition

will only be analyzed once.)

By contrast, if the table being analyzed has inheritance children,

<command>ANALYZE</command> will gather statistics for it twice:

once on the rows of the parent table only, and a second time on the

rows of the parent table with all of its children. This second set of

statistics is needed when planning queries that traverse the entire

inheritance tree. The child tables themselves are not individually

analyzed in this case.

If the table being analyzed has one or more children,

<command>ANALYZE</command> will gather statistics twice: once on the

rows of the parent table only, and a second time on the rows of the

parent table with all of its children. This second set of statistics

is needed when planning queries that traverse the entire inheritance

tree. The autovacuum daemon, however, will only consider inserts or

updates on the parent table itself when deciding whether to trigger an

automatic analyze for that table. If that table is rarely inserted into

or updated, the inheritance statistics will not be up to date unless you

run <command>ANALYZE</command> manually.

</para>

<para>

The autovacuum daemon counts inserts, updates and deletes in the

partitions to determine if auto-analyze is needed. However, adding

or removing partitions does not affect autovacuum daemon decisions,

so triggering a manual <command>ANALYZE</command> is recommended

when this occurs.

</para>

<para>

Tuples changed in inheritance children do not count towards analyze

on the parent table. If the parent table is empty or rarely modified,

it may never be processed by autovacuum. It's necessary to

periodically run a manual <command>ANALYZE</command> to keep the

statistics of the table hierarchy up to date.

</para>

<para>

If any of the child tables or partitions are foreign tables whose foreign data wrappers

If any of the child tables are foreign tables whose foreign data wrappers

do not support <command>ANALYZE</command>, those child tables are ignored while

gathering inheritance statistics.

</para>

If a table parameter value is set and the

equivalent <literal>toast.</literal> parameter is not, the TOAST table

will use the table's parameter value.

Except where noted,these parametersare not supported on partitioned

tables; however,youcan specify themon individual leaf partitions.

Specifyingthese parametersfor partitioned tables is not supported,

butyoumay specify themfor individual leaf partitions.

</para>

<variablelist>

If true, the autovacuum daemon will perform automatic <command>VACUUM</command>

and/or <command>ANALYZE</command> operations on this table following the rules

discussed in <xref linkend="autovacuum"/>.

This parameter can be set for partitioned tables to prevent autovacuum

from running <command>ANALYZE</command> on them.

If false, this table will not be autovacuumed, except to prevent

transaction ID wraparound. See <xref linkend="vacuum-for-wraparound"/> for

more about wraparound prevention.

<para>

Per-table value for <xref linkend="guc-autovacuum-analyze-threshold"/>

parameter.

This parameter can be set for partitioned tables.

</para>

</listitem>

</varlistentry>

<para>

Per-table value for <xref linkend="guc-autovacuum-analyze-scale-factor"/>

parameter.

This parameter can be set for partitioned tables.

</para>

</listitem>

</varlistentry>

<para>

Once restored, it is wise to run <command>ANALYZE</command> on each

restored table so the optimizer has useful statistics.

If the table is a partition or an inheritance child, it may also be useful

to analyze the parent to update statistics for the table hierarchy.

See <xref linkend="vacuum-for-statistics"/> and

restored table so the optimizer has useful statistics; see

<xref linkend="vacuum-for-statistics"/> and

<xref linkend="autovacuum"/> for more information.

</para>

{

"autovacuum_enabled",

"Enables autovacuum in this relation",

RELOPT_KIND_HEAP |RELOPT_KIND_TOAST |RELOPT_KIND_PARTITIONED,

RELOPT_KIND_HEAP |RELOPT_KIND_TOAST,

},

true

{

"autovacuum_analyze_threshold",

"Minimum number of tuple inserts, updates or deletes prior to analyze",

RELOPT_KIND_HEAP |RELOPT_KIND_PARTITIONED,

RELOPT_KIND_HEAP,

},

-1,0,INT_MAX

{

"autovacuum_analyze_scale_factor",

"Number of tuple inserts, updates or deletes prior to analyze as a fraction of reltuples",

RELOPT_KIND_HEAP |RELOPT_KIND_PARTITIONED,

RELOPT_KIND_HEAP,

},

-1,0.0,100.0

partitioned_table_reloptions(Datumreloptions,boolvalidate)

{

returndefault_reloptions(reloptions,validate,RELOPT_KIND_PARTITIONED);

return (bytea*)build_reloptions(reloptions,validate,

RELOPT_KIND_PARTITIONED,

0,NULL,0);

}

PROGRESS_ANALYZE_PHASE_FINALIZE_ANALYZE);

InvalidMultiXactId,

in_outer_xact);

}

}

elseif (onerel->rd_rel->relkind==RELKIND_PARTITIONED_TABLE)

{

vac_update_relstats(onerel,-1,totalrows,

0,hasindex,InvalidTransactionId,

InvalidMultiXactId,

in_outer_xact);

}

if (!inh||onerel->rd_rel->relkind==RELKIND_PARTITIONED_TABLE)

pgstat_report_analyze(onerel,totalrows,totaldeadrows,

(va_cols==NIL));

if (!inh&& !IsAutoVacuumWorkerProcess()&&

(va_cols==NIL)&&

onerel->rd_rel->relpersistence==RELPERSISTENCE_PERMANENT)

{

pgstat_report_anl_ancestors(RelationGetRelid(onerel));

}

static void truncate_check_rel(Oid relid, Form_pg_class reltuple);

static void truncate_check_perms(Oid relid, Form_pg_class reltuple);

static void truncate_check_activity(Relation rel);

static void truncate_update_partedrel_stats(List *parted_rels);

static void RangeVarCallbackForTruncate(const RangeVar *relation,

Oid relId, Oid oldRelId, void *arg);

static List *MergeAttributes(List *schema, List *supers, char relpersistence,

{

List *rels;

List *seq_relids = NIL;

List *parted_rels = NIL;

HTAB *ft_htab = NULL;

EState *estate;

ResultRelInfo *resultRelInfos;

{

Relationrel = (Relation) lfirst(cell);

/*

* Save OID of partitioned tables for later; nothing else to do for

* them here.

*/

/* Skip partitioned tables as there is nothing to do */

if (rel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE)

{

parted_rels = lappend_oid(parted_rels, RelationGetRelid(rel));

continue;

}

/*

* Build the lists of foreign tables belonging to each foreign server

ResetSequence(seq_relid);

}

/* Reset partitioned tables' pg_class.reltuples */

truncate_update_partedrel_stats(parted_rels);

/*

* Write a WAL record to allow this set of actions to be logically

* decoded.

CheckTableNotInUse(rel, "TRUNCATE");

}

/*

* Update pg_class.reltuples for all the given partitioned tables to 0.

*/

static void

truncate_update_partedrel_stats(List *parted_rels)

{

Relationpg_class;

ListCell *lc;

pg_class = table_open(RelationRelationId, RowExclusiveLock);

foreach(lc, parted_rels)

{

Oidrelid = lfirst_oid(lc);

HeapTupletuple;

Form_pg_class rd_rel;

tuple = SearchSysCacheCopy1(RELOID, ObjectIdGetDatum(relid));

if (!HeapTupleIsValid(tuple))

elog(ERROR, "could not find tuple for relation %u", relid);

rd_rel = (Form_pg_class) GETSTRUCT(tuple);

if (rd_rel->reltuples != (float4) 0)

{

rd_rel->reltuples = (float4) 0;

heap_inplace_update(pg_class, tuple);

}

heap_freetuple(tuple);

}

table_close(pg_class, RowExclusiveLock);

}

/*

* storage_name

* returns the name corresponding to a typstorage/attstorage enum value