<!-- -->
<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>
The &slevent; and &slconfirm; tables need to be regularly vacuumed because
&slony1; will often add and delete rows to 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 can
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).  If &slony1; detects that autovacuum has been
disabled for any of the &slony1; tables then it will try to vacuum
the table itself as part of cleanupThread 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 learn about the vacuuming concerns that apply to you.
</para></note>


<sect2>
<title>Log Switching</title>
<para>
&slony1; will frequently switch between &sllog1; and &sllog2; as the 
table that the &slony1; triggers log data into.  Once all of the 
transactions in one of these tables have been replicated &slony1;
will TRUNCATE the table.  The usage of TRUNCATE in this manner
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>
