<!-- $PostgreSQL: pgsql/doc/src/sgml/external-projects.sgml,v 1.11 2006/08/0100:09:06 momjian Exp $ -->

<!-- $PostgreSQL: pgsql/doc/src/sgml/external-projects.sgml,v 1.12 2006/08/0119:17:18 alvherre Exp $ -->

<appendix id="external-projects">

<title>PgFoundry and External Projects</title>

<para>

Secondly, many <productname>PostgreSQL</productname>-related projects are

still hosted at <ulink url="http://gborg.postgresql.org"><productname>GBorg</></ulink>.

still hosted at <ulink url="http://gborg.postgresql.org/"><productname>GBorg</></ulink>.

GBorg is the original external community developer site, and while it is

currently closed to new projects in favor of PgFoundry, it still contains

many active and relevant projects. There are other popular <productname>PostgreSQL</productname>

related projects that are hosted independently as well at other community

sites such as <ulink url="http://www.sf.net">SourceForge</ulink>. You should

google if you don't find the project you are looking for.

sites such as <ulink url="http://www.sf.net/">SourceForge</ulink>. You should

search the web if you don't find the project you are looking for.

</para>

<sect1 id="external-interfaces">

<para>

<productname>PostgreSQL</productname> includes very few interfaces

with the base distribution. <application>libpq</> is packaged because

it is the primary dependecy of most interfaces available to PostgreSQL.

We also package <application>ecpg</> because it is tied to the

server-side grammar. All other interfaces, such as PHP, Perl, Python,

and Ruby, are external projects.

it is the primary <application>C</> interface and many other interfaces

are build on top of it. <application>ecpg</> is also packaged because it is

tied to the server-side grammar so is very dependent on the database

version. All the other interfaces, such as ODBC, Java, Perl, Python, and

others, are external projects and must be installed separately.

</para>

<para>

</varlistentry>

<varlistentry>

<term>pgjdbc</term>

<term>PostgreSQL JDBC Driver</term>

<listitem>

<para>

A <application>JDBC</> interface.

<term>Npgsql</term>

<listitem>

<para>

<application>.Net</>interfaceformore recent<application>mono/C#</> applications.

<application>.Net</>data providerfor <application>C#</> applications.

<ulink url="http://pgfoundry.org/projects/npgsql/">Website.</ulink>

</para>

</listitem>

<term>libpqxx</term>

<listitem>

<para>

Anewer<application>C++</> interface.

A <application>C++</> interface.

<ulink url="http://thaiopensource.org/development/libpqxx/">Website.</ulink>

</para>

</listitem>

<term>pgtclng</term>

<listitem>

<para>

Anewer version of the<application>Tcl</> interface.

A <application>Tcl</> interface.

<ulink url="http://gborg.postgresql.org/project/pgtclng/projdisplay.php">Website.</ulink>

</para>

</listitem>

</varlistentry>

<varlistentry>

<term>Pyscopg</term>

<term>pyscopg</term>

<listitem>

<para>

A <application>Python</> interface library that is DB API 2.0 compliant.

<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.57 2006/08/0100:09:06 momjian Exp $ -->

<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.58 2006/08/0119:17:17 alvherre Exp $ -->

<chapter id="maintenance">

<title>Routine Database Maintenance Tasks</title>

</indexterm>

<indexterm zone="maintenance">

<primary>Routine maintenance</primary>

<primary>routine maintenance</primary>

</indexterm>

<para>

PostgreSQL, like any database software, requires that certain tasks

be performed regularly to achieve optimum performance. The tasks

<productname>PostgreSQL</>, like any database software, requires that certain tasks

be performed regularly to achieve optimum performance. The tasks

discussed here are <emphasis>required</emphasis>, but they

are repetitive in nature and can easily be automated using standard

Unix tools such as <application>cron</application> scripts.

are repetitive in nature and can easily be automated using standard

Unix tools such as <application>cron</application> scripts or

Windows' <application>Task Scheduler</>. But it is the database

administrator's responsibility to set up appropriate scripts, and to

check that they execute successfully.

</para>

<para>

<productname>PostgreSQL</productname> is low-maintenance compared

to other database management systems. It is also fairly easy, provided

you read the documentation.

One obvious maintenance task is creation of backup copies of the data on a

regular schedule. Without a recent backup, you have no chance of recovery

after a catastrophe (disk failure, fire, mistakenly dropping a critical

table, etc.). The backup and recovery mechanisms available in

<productname>PostgreSQL</productname> are discussed at length in

<xref linkend="backup">.

</para>

<para>

There are three tasks that <emphasis>must</emphasis> be performed on

a periodic basis. The first is backups. If you do not have a current backup

and your system experiences a catastrophic failure, you will lose your data.

You can read further about backups procedures in <xref linkend="backup">.

The second is vacuum which is discussed in <xref linkend="routine-vacuuming">.

The third is to update the planner statistics using the analyze command as

discussed in <xref linkend="vacuum-for-statistics">.

The other main category of maintenance task is periodic <quote>vacuuming</>

of the database. This activity is discussed in

<xref linkend="routine-vacuuming">. Closely related to this is to update

the statistics that will be used by the query planner, as discussed in

<xref linkend="vacuum-for-statistics">.

</para>

<para>

Another task thatmay need periodic attention is log file management.

Another task thatmight need periodic attention is log file management.

This is discussed in <xref linkend="logfile-maintenance">.

</para>

<para>

<productname>PostgreSQL</productname> is low-maintenance compared

to some other database management systems. Nonetheless,

appropriate attention to these tasks will go far towards ensuring a

pleasant and productive experience with the system.

</para>

<sect1 id="routine-vacuuming">

<title>Routine Vacuuming</title>

</para>

<para>

The standard form of <command>VACUUM</>does not intefere with production

database operations.Items such asSELECTS, INSERTS, UPDATES andDELETES

The standard form of <command>VACUUM</>can run in parallel with production

database operations.Commands such asSELECTs, INSERTs, UPDATEs andDELETEs

will continue to function as normal, though you will not be able to modify the

definition (Such as ALTER TABLE ADD COLUMN) of a table while it is being vacuumed.

The release of <productname>PostgreSQL</productname> 8.0, introduced new

configuration parameters to further reduce the potentially negative

definition of a table with commands such as ALTER TABLE ADD COLUMN

while it is being vacuumed.

Beginning in <productname>PostgreSQL</productname> 8.0, there are

configuration parameters that can be adjusted to further reduce the

performance impact of background vacuuming. See

<xref linkend="runtime-config-resource-vacuum-cost">.

</para>

<para>

If you have a table whose entire contents are deleted on a periodic

basis, consider doing it withthe<command>TRUNCATE</command> rather

than usingthe<command>DELETE</command> followed by

basis, consider doing it with <command>TRUNCATE</command> rather

than using <command>DELETE</command> followed by

<command>VACUUM</command>. <command>TRUNCATE</command> removes the

entire content of the table immediately, without requiring a

subsequent <command>VACUUM</command> or <command>VACUUM