<!-- -->
<sect1 id="performance">
<title>Performance Considerations</title>
<para>
&slony1; is a trigger based replication engine.  For each row of 
application data you insert, update, or delete in your database 
&slony1; will insert an additional row into the &sllog1; or
&sllog2; tables.  This means that &slony1; will likely have a 
negative impact on your databases performance.  Predicting
this impact is more difficult because the amount of impact
is dependent on your database workload and hardware capabilities.
</para>

<para>
The following &slony1; operations are likely to impact performance:
<itemizedlist>
<listitem>
<para>Changing data in a replicated table will result in rows being added
to &sllog1; or &sllog2;</para></listitem>
<listitem><para>When a slon daemon generates a SYNC event on each node
it will need to add to the &slevent; table.</para></listitem>
<listitem><para> Each remote slon daemon will need to query the &sllog1;, &sllog2; and
&slevent; tables to pull the data to replicate</para>
</listitem>
</itemizedlist>

<sect2>
<title>Vacuum Concerns</title>

<para> Tables &slevent; and &slconfirm; need to be regularly vacuumed
because &slony1; regularly adds and deletes rows to and from these
tables.  The autovacuum feature of &postgres; included in 8.3 and
above is the recommended way of handling vacuums.  If autovacuum does
is not working well, it may be configured to not vacuum the &slevent;
and &slconfirm; tables.  See the &postgres; documentation information
on how to disable autovacuum on a per-table basis.</para>

<itemizedlist>

<listitem><para><ulink
url="http://www.postgresql.org/docs/8.3/static/routine-vacuuming.html#AUTOVACUUM">
&postgres; 8.3 autovacuum </ulink> </para>

<para> Up to &postgres; 8.3, tables requiring special handling for
autovacuum were captured in the system catalog <ulink
url="http://www.postgresql.org/docs/8.3/static/catalog-pg-autovacuum.html">
pg_autovacuum </ulink> table. </para>

</listitem>
<listitem><para><ulink url="http://www.postgresql.org/docs/9.1/static/sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS"> CREATE TABLE parameters </ulink> </para> 

<para> In &postgres; 8.4 and later, autovacuum control is captured as
part of table <quote>storage parameters</quote> using <command>CREATE
TABLE</command> or <command>ALTER TABLE</command>. </para>

</listitem>
</itemizedlist>

<para> When &slony1; detects that autovacuum has been disabled for any
or all of the &slony1; tables then it will try to vacuum such tables
itself as part of <function>cleanupThread</function> processing.
</para>

<note>
<para>Older versions of &slony1; and older versions of &postgres; had
different vacuuming concerns.  If your using an older version of
&slony1; (prior to 2.0) then you should refer to the documentation for
your &slony1; version to determine applicable vacuuming concerns.
</para></note>

<para> It is generally to be expected that the use of autovacuum is to
be preferred, as it allows &slony1; tables to be vacuumed as often or
as seldom as their update patterns indicate.  In cases where
autovacuum does <emphasis>not</emphasis> provide appropriate
maintenance, it seems likely that either:</para>

<itemizedlist>

<listitem><para> Configuration parameters for autovacuum are poorly
set, in which case the <quote>fix</quote> is to improve the
configuration values, or </para> </listitem>

<listitem><para> There is a bug in autovacuum, in which case it
warrants fixing or improving that portion of &postgres;. </para>
</listitem>

</itemizedlist>

<para> There have been some substantial enhancements done to the
autovacuum facility over the course of its history, and it is very
much preferable to take advantage of those efforts rather than
reinventing it, likely badly. </para>

<sect2>
<title>Log Switching</title>

<para>
&slony1; will frequently switch between &sllog1; and &sllog2; as the
table into which the &slony1; triggers capture data.  Once all of the
transactions in one of these tables have been replicated and confirmed
across the whole cluster, &slony1; will <command>TRUNCATE</command>
the table.  This usage of <command>TRUNCATE</command> eliminates the
need to vacuum &sllog1; and &sllog2;.
</para>


<sect2>
<title>
Long Running Transactions
</title>
<para>
Long running transactions can impact the performance of &slony1; because
they prevent Log Switching from occurring.  As long as your oldest transaction
is open it will &sllog1; or &sllog2; from being truncated.  This means that
the other sl_log table will continue to grow in size.  Long running
transactions can also stop &slevent; and sl_confirm from being vacuumed.
The table bloat that occurs due to a long running transaction will
mean that queries to these tables will take longer.  This can lead to
replication falling behind.   If replication is behind then the data
in these tables has remain until that data is replicated.  The increased
size of the &slony1; tables can cause replication to fall even
further behind.


</para>
</sect2>



</sect1>
