-
+
-
External Projects
+
<span class="marked">PgFoundry and </span>External Projects
PostgreSQL is a complex software project,
- and managing it is difficult. We have found that many
+ and managing the project is difficult. We have found that many
enhancements to
PostgreSQL can be more
- efficiently developed separately from the core project. Separate
- projects can
- have their own developer teams, email lists, bug tracking,
- and release schedules. While their independence makes
- development easier, it makes users' jobs harder. They have to hunt
- around looking for database enhancements to meet their needs.
- This section describes some of the more popular externally
- developed enhancements and guides you on how to find them.
+ efficiently developed separately from the core project.
+
+
+ To help our community with the development of their external projects,
+ we have created the
PgFoundry.+
PgFoundry is built using the+ GForge software project and is similar to SourceForge in its feature set. If
+ you have a PostgreSQL related Open Source project that you would like to
+ develop and need project management resources such as mailing lists, forums,
+ bug tracking, and CVS, please feel free to create a new project.
- Many
PostgreSQL-related projects are
- hosted at either
- There are other
PostgreSQL-related projects that are hosted
- elsewhere, but you will have to do an Internet search to find them.
+ Secondly, many
PostgreSQL-related projects are
+ 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
PostgreSQL + related projects that are hosted independently as well at other community
+ sites such as
SourceForge. You should + google if you don't find the project you are looking for.
PostgreSQL includes very few interfaces
with the base distribution.
libpq is packaged because- it is the primary
C interface and many other- interfaces are built on top of it.
ecpg is packaged- because it is tied to the server-side grammar so is very dependent
- on the database version. All the other interfaces are independent
- projects and must be installed separately.
+ it is the primary dependecy of most interfaces available to PostgreSQL.
+ We also package
ecpg because it is tied to the + server-side grammar. All other interfaces, such as PHP, Perl, Python,
+ and Ruby, are external projects.
This is the most common interface for
Windows- applications.
-
-
-
-
-
- pgjdbc
-
- Npgsql
+ ODBCng
-
.Net interface for more recent- <application>Windows applications.
+ Another ODBC driver for PostgreSQL.
+ <ulink url="http://projects.commandprompt.com/public/odbcng/">Website.
- libpqxx
+ pgjdbc
- libpq++
+ Npgsql
- An older
C++ interface.+
.Net interface for more recent mono/C# applications.
- pgperl
+ libpqxx
- A
Perl interface with an API similar
- DBD-Pg
+ DBD::Pg
- A
Perl interface that uses the- <
acronym>DBD-standard API.+ A
Perl DBI driver for PostgreSQL.+ <ulink url="http://search.cpan.org/dist/DBD-Pg/">Website.
A newer version of the
Tcl interface.
- pgtcl
-
- The original version of the
Tcl interface.-
-
-
-
-
- PyGreSQL
+ Pyscopg
- A
Python interface library.+ A
Python interface library that is DB API 2.0 compliant.
-
-
- All of these can be found at
There are several administration tools available for
PostgreSQL. The most popular is
-
pgAdmin, and there are several commercially- available ones.
+ and there are several commercially available ones as well.
-
+
Routine Database Maintenance Tasks
+
+
+
- There are a few routine maintenance chores that must be performed on
- a regular basis to keep a
PostgreSQL- server running smoothly. The tasks discussed here are repetitive
- in nature and can easily be automated using standard Unix tools such
- as
cron scripts. But it is the database
- administrator's responsibility to set up appropriate scripts, and to
- check that they execute successfully.
+ PostgreSQL, like any database software, requires that certain tasks
+ be performed regularly to achieve optimum performance. The tasks
+ discussed here are required, but they
+ are repetitive in nature and can easily be automated using standard
+ Unix tools such as
cron scripts.
-
+
- 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
-
PostgreSQL are discussed at length in
- .
+
PostgreSQL is low-maintenance compared
+ to other database management systems. It is also fairly easy, provided
+ you read the documentation.
- The other main category of maintenance task is periodic vacuuming
- of the database. This activity is discussed in
- .
+ There are three tasks that must 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 .
+ The second is vacuum which is discussed in .
+ The third is to update the planner statistics using the analyze command as
+ discussed in .
- Something else that might need periodic attention is log file management.
+ Another task that may need periodic attention is log file management.
This is discussed in .
-
PostgreSQL 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.
-
+
Routine Vacuuming
PostgreSQL's
VACUUM command
- must be run on a regular basis for several reasons:
+ must be run on a regular basis for several reasons:
- To recover disk space occupied by updated or deleted
+ To recover or reuse disk space occupied by updated or deleted
rows.
- The standard form of VACUUM can run in parallel with
- normal database operations (SELECTs, INSERTs, UPDATEs, DELETEs, but not
- changes to table definitions).
- Beginning in
PostgreSQL 8.0, there are
- configuration parameters that can be adjusted to further reduce the
+ The standard form of VACUUM does not intefere with production
+ database operations. Items such as SELECTS, INSERTS, UPDATES and DELETES
+ 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
PostgreSQL 8.0, introduced new
+ configuration parameters to further reduce the potentially negative
performance impact of background vacuuming. See
.
- If you have a table whose contents are deleted on a periodic
- basis, consider doing it with TRUNCATE rather
- than using DELETE followed by
+ If you have a table whose entire contents are deleted on a periodic
+ basis, consider doing it with the TRUNCATE rather
+ than using the DELETE followed by
VACUUM. TRUNCATE removes the
entire content of the table immediately, without requiring a
subsequent VACUUM or VACUUM
projects / postgresql.git / commitdiff