never issue <command>VACUUM FULL</command>. In this approach, the idea

is not to keep tables at their minimum size, but to maintain steady-state

usage of disk space: each table occupies space equivalent to its

minimum size plus however much space gets used up betweenvacuumings.

minimum size plus however much space gets used up betweenvacuum runs.

Although <command>VACUUM FULL</command> can be used to shrink a table back

to its minimum size and return the disk space to the operating system,

there is not much point in this if the table will just grow again in the

</listitem>

</varlistentry>

<varlistentry id="reloption-autovacuum-vauum-scale-factor" xreflabel="autovacuum_vacuum_scale_factor">

<varlistentry id="reloption-autovacuum-vacuum-scale-factor" xreflabel="autovacuum_vacuum_scale_factor">

<term><literal>autovacuum_vacuum_scale_factor</literal>, <literal>toast.autovacuum_vacuum_scale_factor</literal> (<type>floating point</type>)

<indexterm>

<primary><varname>autovacuum_vacuum_scale_factor</varname> </primary>

</listitem>

</varlistentry>

<varlistentry id="reloption-autovacuum-vauum-cost-limit" xreflabel="autovacuum_vacuum_cost_limit">

<varlistentry id="reloption-autovacuum-vacuum-cost-limit" xreflabel="autovacuum_vacuum_cost_limit">

<term><literal>autovacuum_vacuum_cost_limit</literal>, <literal>toast.autovacuum_vacuum_cost_limit</literal> (<type>integer</type>)

<indexterm>

<primary><varname>autovacuum_vacuum_cost_limit</varname></primary>

If you wish to create a new superuser, you must connect as a

superuser, not merely with <literal>CREATEROLE</literal> privilege.

Being a superuser implies the ability to bypass all access permission

checks within the database, sosuperuserdom should not be granted lightly.

checks within the database, sosuperuser access should not be granted lightly.

</para>

<para>