PostgreSQL wiki - User contributions [en]

Todo

2013-01-27T19:01:07Z

Mastermind:

<div style="margin: 1ex 1em; float: right;">
__TOC__
</div>

This list contains '''known PostgreSQL bugs and feature requests''' and we hope it is complete. If you would like to work on an item, please read the [[Developer FAQ]] first. There is also a [[Development_information|development information page]].

* {{TodoPending}} - marks ordinary, incomplete items
* {{TodoEasy}} - marks items that are easier to implement
* {{TodoDone}} - marks changes that are done, and will appear in the PostgreSQL 9.3 release.

For help on editing this list, please see [[Talk:Todo]]. <b>Please do not add items here without discussion on the mailing list.</b>

<b>For Developers:</b> Unfortunately this list does not contain all the information necessary for someone to start coding a feature. Some of these items might have become unnecessary since they were added --- others might be desirable but the implementation might be unclear. When selecting items listed below, be prepared to first discuss the value of the feature. Do not assume that you can select one, code it and then expect it to be committed. Always discuss design on Hackers list before starting to code. The flow should be:

Desirability -> Design -> Implement -> Test -> Review -> Commit

<div style="padding: 1ex 4em;">
== Administration ==

{{TodoItem
|Allow administrators to cancel multi-statement idle transactions
|This allows locks to be released, but it is complex to report the cancellation back to the client.
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg01340.php <nowiki>Cancelling idle in transaction state</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00441.php <nowiki>Re: Cancelling idle in transaction state</nowiki>]
}}

{{TodoItem
|Check for unreferenced table files created by transactions that were in-progress when the server terminated abruptly
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00096.php <nowiki>Removing unreferenced files</nowiki>]
}}

{{TodoItem
|Set proper permissions on non-system schemas during db creation
|Currently all schemas are owned by the super-user because they are copied from the template1 database. However, since all objects are inherited from the template database, it is not clear that setting schemas to the db owner is correct.}}

{{TodoItem
|Allow log_min_messages to be specified on a per-module basis
|This would allow administrators to see more detailed information from specific sections of the backend, e.g. checkpoints, autovacuum, etc. Another idea is to allow separate configuration files for each module, or allow arbitrary SET commands to be passed to them. See also [[Logging Brainstorm]].}}

{{TodoItem
|Simplify creation of partitioned tables
|This would allow creation of partitioned tables without requiring creation of triggers or rules for INSERT/UPDATE/DELETE, and constraints for rapid partition selection. Options could include range and hash partition selection. See also [[Table partitioning]]
}}

{{TodoItem
|Allow custom variables to appear in pg_settings()
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00850.php <nowiki>Re: count(*) performance improvement ideas</nowiki>]
}}

{{TodoItem
|Have custom variables be transaction-safe
* {{MessageLink|4B577E9F.8000505@dunslane.net|Custom GUCs still a bit broken}}
}}

{{TodoItem
|Implement the SQL-standard mechanism whereby REVOKE ROLE revokes only the privilege granted by the invoking role, and not those granted by other roles
* [http://archives.postgresql.org/pgsql-bugs/2007-05/msg00010.php <nowiki>Re: Grantor name gets lost when grantor role dropped</nowiki>]
}}

{{TodoItem
|Prevent query cancel packets from being replayed by an attacker, especially when using SSL
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg00345.php <nowiki>Replay attack of query cancel</nowiki>]
}}

{{TodoItem
|Provide a way to query the log collector subprocess to determine the name of the currently active log file
* [http://archives.postgresql.org/pgsql-general/2008-11/msg00418.php <nowiki>Current log files when rotating?</nowiki>]
}}

{{TodoItem
|Allow simpler reporting of the unix domain socket directory and allow easier configuration of its default location
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg01555.php
* http://archives.postgresql.org/pgsql-hackers/2011-10/msg01482.php
}}

{{TodoItem
|Allow custom daemons to be automatically stopped/started along with the postmaster
|This allows easier administration of daemons like user job schedulers or replication-related daemons.
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01701.php <nowiki>Re: scheduler in core</nowiki>]
}}

{{TodoItem
|Improve logging of prepared transactions recovered during startup
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg00092.php <nowiki>"recovering prepared transaction" after server restart message</nowiki>]
}}

{{TodoItemDone
|Consider using POSIX shared memory to avoid System V shared memory kernel limits
* [http://archives.postgresql.org/message-id/4DFA2673.3010009@enterprisedb.com <nowiki>POSIX shared memory patch status</nowiki>]
}}

=== Configuration files ===
{{TodoSubsection}}

{{TodoItemDone
|Change pg_ident.conf parsing to be the same as pg_hba.conf
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg02204.php
}}

{{TodoItem
|Allow postgresql.conf file values to be changed via an SQL API, perhaps using SET GLOBAL
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00764.php
* http://archives.postgresql.org/pgsql-hackers/2012-10/msg01509.php
* http://archives.postgresql.org/pgsql-hackers/2012-11/msg00002.php
}}

{{TodoItem
|Consider normalizing fractions in postgresql.conf, perhaps using '%'
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00550.php <nowiki>Fractions in GUC variables</nowiki>]
}}

{{TodoItem
|Allow Kerberos to disable stripping of realms so we can check the username@realm against multiple realms
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00009.php <nowiki>krb_match_realm patch</nowiki>]
}}

{{TodoItem
|Improve LDAP authentication configuration options
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01745.php <nowiki>Proposed Patch - LDAPS support for servers on port 636 w/o TLS</nowiki>]
}}

{{TodoItem
|Add external tool to auto-tune some postgresql.conf parameters
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00000.php <nowiki>Re: Overhauling GUCS</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00033.php <nowiki>Simple postgresql.conf wizard</nowiki>]
}}

{{TodoItem
|Add 'hostgss' pg_hba.conf option to allow GSS link-level encryption
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg01454.php <nowiki>Re: Plans for 8.4</nowiki>]
}}

{{TodoItem
|Process pg_hba.conf keywords as case-insensitive
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00432.php <nowiki>More robust pg_hba.conf parsing/error logging</nowiki>]
}}

{{TodoItem
|Create utility to compute accurate random_page_cost value
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00162.php
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00362.php
}}

{{TodoItem
|Allow configuration files to be independently validated
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01831.php
* http://archives.postgresql.org/message-id/12666.1310774573@sss.pgh.pa.us
}}

{{TodoItem
|Allow postgresql.conf settings to be accepted by backends even if some settings are invalid for those backends
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00330.php
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00375.php
}}

{{TodoItem
|Allow all backends to receive postgresql.conf setting changes at the same time
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00330.php
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00375.php
}}

{{TodoItem
|Allow synchronous_standby_names to be disabled after communication failure with all synchronous standby servers exceeds some timeout
|This also requires successful execution of a synchronous notification command.
* http://archives.postgresql.org/pgsql-hackers/2012-07/msg00409.php
}}

{{TodoEndSubsection}}

=== Tablespaces ===
{{TodoSubsection}}

{{TodoItem
|Allow a database in tablespace t1 with tables created in tablespace t2 to be used as a template for a new database created with default tablespace t2
|Currently all objects in the default database tablespace must have default tablespace specifications. This is because new databases are created by copying directories. If you mix default tablespace tables and tablespace-specified tables in the same directory, creating a new database from such a mixed directory would create a new database with tables that had incorrect explicit tablespaces. To fix this would require modifying pg_class in the newly copied database, which we don't currently do.}}

{{TodoItem
|Allow reporting of which objects are in which tablespaces
|This item is difficult because a tablespace can contain objects from multiple databases. There is a server-side function that returns the databases which use a specific tablespace, so this requires a tool that will call that function and connect to each database to find the objects in each database for that tablespace.}}

{{TodoItem
|Allow WAL replay of CREATE TABLESPACE to work when the directory structure on the recovery computer is different from the original}}

{{TodoItem
|Allow per-tablespace quotas}}

{{TodoItem
|Allow tablespaces on RAM-based partitions for unlogged tables
* http://archives.postgresql.org/pgsql-advocacy/2011-05/msg00033.php
}}

{{TodoItem
|Allow toast tables to be moved to a different tablespace
* [http://archives.postgresql.org/pgsql-hackers/2011-05/msg00980.php]
* {{messageLink|CAFEQCbH756DyyAPQ1ykh3+b+kE1-EhWRww1WO_x5v38C-uLnUg@mail.gmail.com|patch : Allow toast tables to be moved to a different tablespace}} (issues remain)
* [http://archives.postgresql.org/message-id/CAFEQCbEq07OopgE5xFYv2Q3eMq45hRSJkjCBO+kvpJq9NEVhow@mail.gmail.com Allow toast tables to be moved to a different tablespace]
}}

{{TodoEndSubsection}}

=== Statistics Collector ===
{{TodoSubsection}}

{{TodoItem
|Allow statistics last vacuum/analyze execution times to be displayed without requiring track_counts to be enabled
* [http://archives.postgresql.org/pgsql-docs/2007-04/msg00028.php <nowiki>row-level stats and last analyze time</nowiki>]
}}

{{TodoItem
|Clear table counters on TRUNCATE
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg00169.php <nowiki>Small TRUNCATE glitch</nowiki>]
}}

{{TodoEndSubsection}}

=== SSL ===
{{TodoSubsection}}

{{TodoItem
|Allow SSL authentication/encryption over unix domain sockets
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00924.php <nowiki>Re: Spoofing as the postmaster</nowiki>]
}}

{{TodoItem
|Allow SSL key file permission checks to be optionally disabled when sharing SSL keys with other applications
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00069.php <nowiki>BUG #3809: SSL "unsafe" private key permissions bug</nowiki>]
}}

{{TodoItem
|Allow SSL CRL files to be re-read during configuration file reload, rather than requiring a server restart
|Unlike SSL CRT files, CRL (Certificate Revocation List) files are updated frequently
* [http://archives.postgresql.org/pgsql-general/2008-12/msg00832.php <nowiki>Automatic CRL reload</nowiki>]
Alternatively or additionally supporting OCSP (online certificate security protocol) would provide real-time revocation discovery without reloading
}}

{{TodoItem
| Allow automatic selection of SSL client certificates from a certificate store
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00406.php <nowiki>Allow multiple certificates or keys in the postgresql.crt/.key files</nowiki>]
}}

{{TodoItem
| Send the full certificate server chain to the client
* [http://archives.postgresql.org/pgsql-bugs/2009-12/msg00145.php BUG #5245: Full Server Certificate Chain Not Sent to client]
}}

{{TodoEndSubsection}}

=== Point-In-Time Recovery (PITR) ===
{{TodoSubsection}}

{{TodoItemEasy
|Create dump tool for write-ahead logs for use in determining transaction id for point-in-time recovery
|This is useful for checking PITR recovery.}}

{{TodoItem
|Allow archive_mode to be changed without server restart?
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01655.php <nowiki>Enabling archive_mode without restart</nowiki>]
}}

{{TodoItem
|Consider avoiding WAL switching via archive_timeout if there has been no database activity
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg01469.php <nowiki>archive_timeout behavior for no activity</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg00395.php <nowiki>Re: archive_timeout behavior for no activity</nowiki>]
}}

{{TodoItem
|Allow base backup from standby to continue when the standby is promoted.
* [http://archives.postgresql.org/pgsql-hackers/2012-10/msg00239.php <nowiki>Re: Promoting a standby during base backup</nowiki>]
}}

{{TodoEndSubsection}}

=== Standby server mode ===
{{TodoSubsection}}

{{TodoItem
| Allow pg_xlogfile_name() to be used in recovery mode
* [http://archives.postgresql.org/message-id/3f0b79eb1001190135vd9f62f1sa7868abc1ea61d12@mail.gmail.com <nowiki>Streaming replication and pg_xlogfile_name()</nowiki>]
}}

{{TodoItem
| Prevent variables inherited from the server environment from begin used for making streaming replication connections.
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01011.php <nowiki>Re: Parameter name standby_mode</nowiki>]
}}

{{TodoItem
| Change walsender so that it applies per-role settings
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg00642.php
}}

{{TodoItem
| Restructure configuration parameters for standby mode
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg01820.php
}}

{{TodoItemf
| Allow time-delayed application of logs on the standby
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00992.php
}}

{{TodoItem
| Add -X parameter to pg_basebackup to specify a different directory for px_xlog, like initdb
}}

{{TodoItem
| Add a new "eager" synchronous mode that starts out synchronous but reverts to asynchronous after a failure timeout period
|This would require some type of command to be executed to alert administrators of this change.
* http://archives.postgresql.org/pgsql-hackers/2011-12/msg01224.php
}}

{{TodoEndSubsection}}

== Data Types ==

{{TodoItem
|Fix data types where equality comparison is not intuitive, e.g. box
* http://archives.postgresql.org/pgsql-hackers/2011-10/msg01643.php
}}

{{TodoItem
|Add support for public SYNONYMs
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00519.php <nowiki>Proposal for SYNONYMS</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg02043.php
* http://archives.postgresql.org/pgsql-general/2010-12/msg00139.php
}}

{{TodoItem
|Add support for SQL-standard GENERATED/IDENTITY columns
* [http://archives.postgresql.org/pgsql-hackers/2006-07/msg00543.php <nowiki>Re: Three weeks left until feature freeze</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-08/msg00038.php <nowiki>GENERATED ... AS IDENTITY, Was: Re: Feature Freeze</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00344.php <nowiki>Behavior of GENERATED columns per SQL2003</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00076.php <nowiki>Re: [HACKERS] Behavior of GENERATED columns per SQL2003</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00604.php <nowiki>IDENTITY/GENERATED patch</nowiki>]
}}

{{TodoItem
|Consider placing all sequences in a single table, or create a system view
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2012-02/msg00258.php Removing special case OID generation]
}}

{{TodoItem
|Consider a special data type for regular expressions
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg01067.php <nowiki>Why is there a tsquery data type?</nowiki>]
}}

{{TodoItem
|Reduce BIT data type overhead using short varlena headers
* [http://archives.postgresql.org/pgsql-general/2007-12/msg00273.php <nowiki>storage size of "bit" data type..</nowiki>]
}}

{{TodoItem
|Allow renaming and deleting enumerated values from an existing enumerated data type
}}

{{TodoItem
|Support scoped IPv6 addresses in the inet type
* [http://archives.postgresql.org/pgsql-bugs/2007-05/msg00111.php <nowiki>strange problem with ip6</nowiki>]
}}

{{TodoItem
|Considering improving performance of computing CHAR() value lengths
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00900.php <nowiki>char() overhead on read-only workloads not so insignifcant as the docs claim it is...</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01787.php <nowiki>Re: [PATCH] backend: compare word-at-a-time in bcTruelen</nowiki>]
}}

{{TodoItem
|Add overlaps geometric operators that ignore point overlaps
* http://archives.postgresql.org/pgsql-hackers/2010-03/msg00861.php
}}

{{TodoItem
|Remove or improve rounding in geometric comparison operators
* http://archives.postgresql.org/message-id/9804.1346187849@sss.pgh.pa.us
}}

{{TodoItem
| Add IMMUTABLE column attribute
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg00623.php
}}

=== Domains ===
{{TodoSubsection}}

{{TodoItem
|Allow functions defined as casts to domains to be called during casting
* [http://archives.postgresql.org/pgsql-hackers/2006-05/msg00072.php <nowiki>bug? non working casts for domain</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-09/msg01681.php <nowiki>TODO: Fix CREATE CAST on DOMAINs</nowiki>]
}}

{{TodoItem
|Allow values to be cast to domain types
* [http://archives.postgresql.org/pgsql-hackers/2003-06/msg01206.php <nowiki>Domain casting still doesn't work right</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00289.php <nowiki>domain casting?</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00812.php
}}

{{TodoItem
|Make domains work better with polymorphic functions
* [http://archives.postgresql.org/message-id/4887.1228700773@sss.pgh.pa.us Polymorphic types vs. domains]
* [http://archives.postgresql.org/message-id/15535.1238774571@sss.pgh.pa.us some difficulties with fixing it]
}}

{{TodoEndSubsection}}

=== Dates and Times ===
{{TodoSubsection}}

{{TodoItem
|Allow infinite intervals just like infinite timestamps
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg00076.php
}}

{{TodoItem
|Determine how to represent date/time field extraction on infinite timestamps
* [http://archives.postgresql.org/message-id/CA+mi_8bda-Fnev9iXeUbnqhVaCWzbYhHkWoxPQfBca9eDPpRMw@mail.gmail.com extract(epoch from infinity) is not 0]
* [http://archives.postgresql.org/message-id/CADAkt-icuESH16uLOCXbR-dKpcvwtUJE4JWXnkdAjAAwP6j12g@mail.gmail.com converting between infinity timestamp and float8]
}}

{{TodoItem
|Allow TIMESTAMP WITH TIME ZONE to store the original timezone information, either zone name or offset from UTC
|If the TIMESTAMP value is stored with a time zone name, interval computations should adjust based on the time zone rules.
* [http://archives.postgresql.org/pgsql-hackers/2004-10/msg00705.php <nowiki>timestamp with time zone a la sql99</nowiki>]
}}

{{TodoItem
|Have timestamp subtraction not call justify_hours()?
* [http://archives.postgresql.org/pgsql-sql/2006-10/msg00059.php <nowiki>timestamp subtraction (was Re: formatting intervals with to_char)</nowiki>]
}}

{{TodoItem
|Improve TIMESTAMP WITH TIME ZONE subtraction to be DST-aware
|Currently subtracting one date from another that crosses a daylight savings time adjustment can return '1 day 1 hour', but adding that back to the first date returns a time one hour in the future. This is caused by the adjustment of '25 hours' to '1 day 1 hour', and '1 day' is the same time the next day, even if daylight savings adjustments are involved.}}

{{TodoItem
|Fix interval display to support values exceeding 2^31 hours}}

{{TodoItem
|Add overflow checking to timestamp and interval arithmetic}}

{{TodoItem
|Add function to allow the creation of timestamps using parameters
* http://archives.postgresql.org/pgsql-performance/2010-06/msg00232.php
}}

{{TodoEndSubsection}}

=== Arrays ===
{{TodoSubsection}}

{{TodoItem
|Add support for arrays of domains
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00114.php <nowiki>Re: updated WIP: arrays of composites</nowiki>]
}}

{{TodoItem
|Allow single-byte header storage for array elements}}

{{TodoItem
|Add function to detect if an array is empty
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00475.php <nowiki>Re: array_length()</nowiki>]
}}

{{TodoItem
|Improve handling of empty arrays
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01033.php <nowiki>So what's an "empty" array anyway?</nowiki>]
* http://archives.postgresql.org/pgsql-general/2012-07/msg00633.php
}}

{{TodoItem
|Improve handling of NULLs in arrays
* [http://archives.postgresql.org/pgsql-bugs/2008-11/msg00009.php <nowiki>BUG #4509: array_cat's null behaviour is inconsistent</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg01040.php
}}

{{TodoEndSubsection}}

=== Binary Data ===
{{TodoSubsection}}

{{TodoItem
|Improve vacuum of large objects, like contrib/vacuumlo?}}

{{TodoItem
|Auto-delete large objects when referencing row is deleted
|contrib/lo offers this functionality.}}

{{TodoItem
|Allow read/write into TOAST values like large objects
|Writing might require the TOAST column to be stored EXTERNAL.
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00049.php
}}

{{TodoItemDone
|Add API for 64-bit large object access
* [http://archives.postgresql.org/pgsql-hackers/2005-09/msg00781.php <nowiki>64-bit API for large objects</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg01790.php
}}

{{TodoEndSubsection}}

=== MONEY Data Type ===
{{TodoSubsection}}

{{TodoItem
|Add locale-aware MONEY type, and support multiple currencies
* [http://archives.postgresql.org/pgsql-general/2005-08/msg01432.php <nowiki>A real currency type</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01181.php <nowiki>Money type todos?</nowiki>]
}}

{{TodoItem
|MONEY dumps in a locale-specific format making it difficult to restore to a system with a different locale}}

{{TodoEndSubsection}}

=== Text Search ===
{{TodoSubsection}}

{{TodoItem
|Allow dictionaries to change the token that is passed on to later dictionaries
* [http://archives.postgresql.org/pgsql-patches/2007-11/msg00081.php <nowiki>a tsearch2 (8.2.4) dictionary that only filters out stopwords</nowiki>]
}}

{{TodoItem
|Consider a function-based API for '@@' searches
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00511.php <nowiki>Simplifying Text Search</nowiki>]
}}

{{TodoItem
|Improve text search error messages
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00966.php <nowiki>Poorly designed tsearch NOTICEs</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg01146.php <nowiki>Re: Poorly designed tsearch NOTICEs</nowiki>]
}}

{{TodoItem
|Consider changing error to warning for strings larger than one megabyte
* [http://archives.postgresql.org/pgsql-bugs/2008-02/msg00190.php <nowiki>BUG #3975: tsearch2 index should not bomb out of 1Mb limit</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-03/msg00062.php <nowiki>Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit</nowiki>]
}}

{{TodoItem
|tsearch and tsdicts regression tests fail in Turkish locale on glibc
* [http://archives.postgresql.org/message-id/49749645.5070801@gmx.net tsearch with Turkish locale]
}}

{{TodoItem
|tsquery negator operator treated as part of lexeme
* [http://archives.postgresql.org/pgsql-bugs/2009-06/msg00346.php BUG #4887: inclusion operator (@>) on tsqeries behaves not conforming to documentation]
}}

{{TodoItem
|Improve handling of dash and plus signs in email address user names, and perhaps improve URL parsing
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00772.php
* [http://archives.postgresql.org/message-id/E1Ri8il-0008Ct-9p@wrigleys.postgresql.org tsearch does not recognize all valid emails]
}}

{{TodoItem
|Improve default parser, to more easily allow adding new tokens
* http://archives.postgresql.org/message-id/23485.1297727826@sss.pgh.pa.us
}}

{{TodoItem
|Add additional support functions
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00319.php
}}

{{TodoEndSubsection}}

=== XML ===
{{TodoSubsection}}

{{TodoItem
|Allow XML arrays to be cast to other data types
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00981.php <nowiki>proposal casting from XML[] to int[], numeric[], text[]</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00231.php <nowiki>Re: proposal casting from XML[] to int[], numeric[], text[]</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00471.php <nowiki>Re: proposal casting from XML[] to int[], numeric[], text[]</nowiki>]
}}

{{TodoItem
|Add XML Schema validation and xmlvalidate functions (SQL:2008)}}

{{TodoItem
|Add xmlvalidatedtd variant to support validating against a DTD?}}

{{TodoItem
|Relax-NG validation; libxml2 supports this already}}

{{TodoItem
|Allow reliable XML operation non-UTF8 server encodings (xpath(), in particular, is known to not work)
* [http://archives.postgresql.org/pgsql-bugs/2009-01/msg00135.php <nowiki>BUG #4622: xpath only work in utf-8 server encoding</nowiki>]
* http://archives.postgresql.org/message-id/4110.1238973350@sss.pgh.pa.us}}

{{TodoItem
|Add functions from SQL:2006: XMLDOCUMENT, XMLCAST, XMLTEXT}}

{{TodoItem
|Add XMLNAMESPACES support in XMLELEMENT and elsewhere}}

{{TodoItem
|Move XSLT from contrib/xml2 to a more reasonable location
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00539.php
}}

{{TodoItem
|Report errors returned by the XSLT library
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00562.php
}}

{{TodoItem
|Improve the XSLT parameter passing API
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00416.php
}}

{{TodoItem
|XML Canonical: Convert XML documents to canonical form to compare them. libxml2 has support for this.}}

{{TodoItem
|Add pretty-printed XML output option
|Parse a document and serialize it back in some indented form. libxml2 might support this.}}

{{TodoItem
|Add XMLQUERY (from the SQL/XML standard)}}

{{TodoItem
|Allow XML sthredding
|In some cases shredding could be better option (if there is no need to keep XML docs entirely, e.g. if we have already developed tools that understand only relational data. This would be a separate module that implements annotated schema decomposition technique, similar to DB2 and SQL Server functionality.}}

{{TodoItem
|Fix Nested or repeated xpath() that apparently mess up namespaces [http://archives.postgresql.org/pgsql-bugs/2008-03/msg00097.php] [http://archives.postgresql.org/pgsql-bugs/2008-03/msg00144.php] [http://archives.postgresql.org/pgsql-general/2008-03/msg00295.php] [http://archives.postgresql.org/pgsql-bugs/2008-07/msg00054.php] [http://archives.postgresql.org/message-id/004f01c90e91$138e9d10$3aabd730$@anstett@iaas.uni-stuttgart.de]}}

{{TodoItem
|XPath: Adding the <x> at the root causes problems [http://archives.postgresql.org/pgsql-bugs/2008-05/msg00184.php] [http://archives.postgresql.org/pgsql-bugs/2008-07/msg00054.php] [http://archives.postgresql.org/pgsql-general/2008-07/msg00613.php]}}

{{TodoItem
|xpath_table needs to be implemented/implementable to get rid of contrib/xml2 [http://archives.postgresql.org/pgsql-general/2008-05/msg00823.php]}}

{{TodoItem
|xpath_table is pretty broken anyway [http://archives.postgresql.org/pgsql-hackers/2010-02/msg02424.php]}}

{{TodoItem
|better handling of XPath data types [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00616.php] [http://archives.postgresql.org/message-id/004a01c90e90$4b986d90$e2c948b0$@anstett@iaas.uni-stuttgart.de]}}

{{TodoItem
|Improve handling of PIs and DTDs in xmlconcat() [http://archives.postgresql.org/message-id/200904211211.n3LCB09p008988@wwwmaster.postgresql.org]}}

{{TodoItem
|Restructure XML and /contrib/xml2 functionality
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02314.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00017.php
}}

{{TodoEndSubsection}}

== Functions ==

{{TodoItem
|Allow INET subnet comparisons using non-constants to be indexed}}

{{TodoItem
|Add an INET overlaps operator, for use by exclusion constraints
* http://archives.postgresql.org/pgsql-hackers/2010-03/msg00845.php
}}

{{TodoItem
|Enforce typmod for function inputs, function results and parameters for spi_prepare'd statements called from PLs
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg01403.php <nowiki>Re: BUG #2917: spi_prepare doesn't accept typename aliases</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg01160.php <nowiki>RFC for adding typmods to functions</nowiki>]
}}

{{TodoItem
|Fix IS OF so it matches the ISO specification, and add documentation
* [http://archives.postgresql.org/pgsql-patches/2003-08/msg00060.php <nowiki>Re: [HACKERS] IS OF</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00060.php <nowiki>ToDo: add documentation for operator IS OF</nowiki>]
}}

{{TodoItem
|Implement Boyer-Moore searching in LIKE queries
* {{messageLink|27645.1220635769@sss.pgh.pa.us|TODO item: Implement Boyer-Moore searching (First time hacker)}}
}}

{{TodoItem
|Prevent malicious functions from being executed with the permissions of unsuspecting users
|Index functions are safe, so VACUUM and ANALYZE are safe too. Triggers, CHECK and DEFAULT expressions, and rules are still vulnerable.
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00268.php <nowiki>Some notes about the index-functions security vulnerability</nowiki>]
}}

{{TodoItem
|Reduce memory usage of aggregates in set returning functions
* [http://archives.postgresql.org/pgsql-performance/2008-01/msg00031.php <nowiki>Re: Performance of aggregates over set-returning functions</nowiki>]
}}

{{TodoItem
|Fix /contrib/ltree operator
* [http://archives.postgresql.org/pgsql-bugs/2007-11/msg00044.php <nowiki>BUG #3720: wrong results at using ltree</nowiki>]
}}

{{TodoItem
|Fix /contrib/btree_gist's implementation of inet indexing
* [http://archives.postgresql.org/pgsql-bugs/2010-10/msg00099.php <nowiki>BUG #5705: btree_gist: Index on inet changes query result</nowiki>]
}}

{{TodoItem
|<nowiki>Fix inconsistent precedence of =, >, and < compared to <>, >=, and <=</nowiki>
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00145.php <nowiki>BUG #3822: Nonstandard precedence for comparison operators</nowiki>]
}}

{{TodoItem
|Fix regular expression bug when using complex back-references
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00000.php <nowiki>BUG #3645: regular expression back references seem broken</nowiki>]
}}

{{TodoItem
|Have /contrib/dblink reuse unnamed connections
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00895.php <nowiki>dblink un-named connection doesn't get re-used</nowiki>]
}}

{{TodoItem
|Improve formatting of pg_get_viewdef() output
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg01648.php <nowiki>pg_get_viewdef formattiing</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01885.php <nowiki>Re: pretty print viewdefs</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2011-12/msg00906.php reprise: pretty print viewdefs]
}}

{{TodoItem
|Add function to dump pg_depend information cleanly
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00226.php <nowiki>Elementary dependency look-up</nowiki>]
}}

{{TodoItem
|Add function to allow easier transaction id comparisons
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg00786.php
}}

=== Character Formatting ===

{{TodoSubsection}}
{{TodoItem
|Allow to_date() and to_timestamp() to accept localized month names}}

{{TodoItem
|Add missing parameter handling in to_char()
* [http://archives.postgresql.org/pgsql-hackers/2005-12/msg00948.php <nowiki>Re: to_char and i18n</nowiki>]
}}

{{TodoItem
|Throw an error from to_char() instead of printing a string of "#" when a number doesn't fit in the desired output format.
* discussed in [http://archives.postgresql.org/message-id/37ed240d0907290836w42187222n18664dfcbcb445b1@mail.gmail.com "to_char, support for EEEE format"]
}}

{{TodoItem
|Allow to_char() on interval values to accumulate the highest unit requested
|2= Some special format flag would be required to request such accumulation. Such functionality could also be added to EXTRACT. Prevent accumulation that crosses the month/day boundary because of the uneven number of days in a month.
* to_char(INTERVAL '1 hour 5 minutes', 'MI') => 65
* to_char(INTERVAL '43 hours 20 minutes', 'MI' ) => 2600
* to_char(INTERVAL '43 hours 20 minutes', 'WK:DD:HR:MI') => 0:1:19:20
* to_char(INTERVAL '3 years 5 months','MM') => 41
}}

{{TodoItem
|Fix to_number() handling for values not matching the format string
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg01447.php <nowiki>Re: numeric_to_number() function skipping some digits</nowiki>]
}}

{{TodoEndSubsection}}

== Multi-Language Support ==

{{TodoItem
|Add NCHAR (as distinguished from ordinary varchar),}}

{{TodoItem
|Add a cares-about-collation column to pg_proc, so that unresolved-collation errors can be thrown at parse time
* [http://archives.postgresql.org/pgsql-hackers/2011-03/msg01520.php <nowiki>Open issues for collations</nowiki>]
}}

{{TodoItem
|Integrate collations with text search configurations
* [http://archives.postgresql.org/message-id/28887.1303579034@sss.pgh.pa.us <nowiki>Some TODO items for collations</nowiki>]
}}

{{TodoItem
|Integrate collations with to_char() and related functions
* [http://archives.postgresql.org/message-id/28887.1303579034@sss.pgh.pa.us <nowiki>Some TODO items for collations</nowiki>]
}}

{{TodoItem
|Support collation-sensitive equality and hashing functions
* [http://archives.postgresql.org/pgsql-hackers/2011-06/msg00472.php <nowiki> contrib/citext versus collations</nowiki>]
}}

{{TodoItem
|Add a LOCALE option to CREATE DATABASE, as a shorthand
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00119.php <nowiki> Re: 8.4 open items list</nowiki>]
}}

{{TodoItem
|Support multiple simultaneous character sets, per SQL:2008}}

{{TodoItem
|Improve UTF8 combined character handling?}}

{{TodoItem
|Add octet_length_server() and octet_length_client()}}

{{TodoItem
|Make octet_length_client() the same as octet_length()?}}

{{TodoItem
|Fix problems with wrong runtime encoding conversion for NLS message files}}

{{TodoItem
|Add URL to more complete multi-byte regression tests
* [http://archives.postgresql.org/pgsql-hackers/2005-07/msg00272.php <nowiki>Multi-byte and client side character encoding tests for copy command..</nowiki>]
}}

{{TodoItem
|Fix contrib/fuzzystrmatch to work with multibyte encodings
* [http://archives.postgresql.org/pgsql-bugs/2009-04/msg00047.php <nowiki> soundex function returns UTF-16 characters</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00138.php <nowiki> dmetaphone woes</nowiki>]
}}

{{TodoItem
|Change memory allocation for multi-byte functions so memory is allocated inside conversion functions
|Currently we preallocate memory based on worst-case usage.}}

{{TodoItem
|Add ability to use case-insensitive regular expressions on multi-byte characters
|Currently it works for UTF-8, but not other multi-byte encodings
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00433.php <nowiki>Regexps vs. locale</nowiki>]
* {{MessageLink|20091201210024.B1393753FB7@cvs.postgresql.org|A partial solution for UTF-8}}
}}

{{TodoItem
|Improve encoding of connection startup messages sent to the client
|Currently some authentication error messages are sent in the server encoding
* [http://archives.postgresql.org/pgsql-general/2008-12/msg00801.php <nowiki>encoding of PostgreSQL messages</nowiki>]
* [http://archives.postgresql.org/pgsql-general/2009-01/msg00005.php <nowiki>Re: encoding of PostgreSQL messages</nowiki>]
}}

{{TodoItem
|More sensible support for Unicode combining characters, normal forms
* http://archives.postgresql.org/message-id/200904141532.44618.peter_e@gmx.net
}}

== Views / Rules ==

{{TodoItemDone
|Automatically create rules on views so they are updateable, per SQL:2008
|We can only auto-create rules for simple views. For more complex cases users will still have to write rules manually.
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00586.php <nowiki>Proposal for updatable views</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2006-08/msg00255.php <nowiki>Updatable views</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg01746.php <nowiki>Re: [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle</nowiki>]
* http://wiki.postgresql.org/wiki/Updatable_views
* http://archives.postgresql.org/pgsql-hackers/2012-07/msg00035.php
* http://archives.postgresql.org/pgsql-hackers/2012-08/msg00303.php
}}

{{TodoItem
|Add the functionality of the WITH CHECK OPTION clause to CREATE VIEW
}}

{{TodoItem
|Allow VIEW/RULE recompilation when the underlying tables change
|This is both difficult and controversial.
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01723.php Re: About "Allow VIEW/RULE recompilation when the underlying tables change"]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01724.php Re: About "Allow VIEW/RULE recompilation when the underlying tables change2"]
* [http://archives.postgresql.org/message-id/CACk%3DU9NFSzWrEba8G5dZ%3DTZLy3_hx3QXGyCcKVWT%3D4iA1FjMuA@mail.gmail.com VIEW still referring to old name of field]
}}

{{TodoItem
|Make it possible to use RETURNING together with conditional DO INSTEAD rules, such as for partitioning setups
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00577.php <nowiki>RETURNING and DO INSTEAD ... Intentional or not?</nowiki>]
}}

{{TodoItem
|Add the ability to automatically create materialized views
|Right now materialized views require the user to create triggers on the main table to keep the summary table current. SQL syntax should be able to manage the triggers and summary table automatically. A more sophisticated implementation would automatically retrieve from the summary table when the main table is referenced, if possible. See [[Materialized Views]] for implementation details
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00479.php <nowiki>GSoC - proposal - Materialized Views in PostgreSQL</nowiki>]
}}

{{TodoItem
|Improve ability to modify views via ALTER TABLE
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00691.php <nowiki>Re: idea: storing view source in system catalogs</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg01410.php <nowiki>modifying views</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg00300.php <nowiki>Re: patch: Add columns via CREATE OR REPLACE VIEW</nowiki>]
}}

== SQL Commands ==

{{TodoItem
|Add CORRESPONDING BY to UNION/INTERSECT/EXCEPT
* [http://dissipatedheat.com/2011/11/10/how-not-to-write-a-patch-for-postgresql/ How not to write this patch.]
}}

{{TodoItem
|Improve type determination of unknown (NULL or quoted literal) result columns for UNION/INTERSECT/EXCEPT
* [http://archives.postgresql.org/message-id/9799.1302719551@sss.pgh.pa.us <nowiki>UNION construct type cast gives poor error message</nowiki>]
}}

{{TodoItem
|Add ROLLUP, CUBE, GROUPING SETS options to GROUP BY
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00838.php <nowiki>WIP: grouping sets support</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00466.php <nowiki>Implementation of GROUPING SETS (T431: Extended grouping capabilities)</nowiki>]
}}

{{TodoItem
|Allow prepared transactions with temporary tables created and dropped in the same transaction, and when an ON COMMIT DELETE ROWS temporary table is accessed
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00047.php <nowiki>Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables</nowiki>]
* [http://archives.postgresql.org/message-id/492543D5.9050904@enterprisedb.com A suggestion on how to implement this]
}}

{{TodoItem
|Add a GUC variable to warn about non-standard SQL usage in queries}}

{{TodoItem
|Add SQL-standard MERGE/REPLACE/UPSERT command
|MERGE is typically used to merge two tables. REPLACE or UPSERT command does UPDATE, or on failure, INSERT. See [[SQL MERGE]] for notes on the implementation details.
}}

{{TodoItem
|Add NOVICE output level for helpful messages
|For example, have it warn about unjoined tables. This could also control automatic sequence/index creation messages.
}}

{{TodoItem
|Allow NOTIFY in rules involving conditionals}}

{{TodoItem
|Allow EXPLAIN to identify tables that were skipped because of constraint_exclusion
}}

{{TodoItem
|Simplify dropping roles that have objects in several databases}}

{{TodoItem
|Allow the count returned by SELECT, etc to be represented as an int64 to allow a higher range of values}}

{{TodoItem
|Add support for WITH RECURSIVE ... CYCLE
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00291.php <nowiki>WITH RECURSIVE ... CYCLE in vanilla SQL: issues with arrays of rows</nowiki>]}}

{{TodoItem
|Add DEFAULT .. AS OWNER so permission checks are done as the table owner
|This would be useful for SERIAL nextval() calls and CHECK constraints.}}

{{TodoItem
|Allow DISTINCT to work in multiple-argument aggregate calls}}

{{TodoItem
|Add comments on system tables/columns using the information in catalogs.sgml
|Ideally the information would be pulled from the SGML file automatically.}}

{{TodoItem
|Prevent the specification of conflicting transaction read/write options
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00684.php <nowiki>Re: SET TRANSACTION and SQL Standard</nowiki>]
}}

{{TodoItemDone
|Support LATERAL subqueries
|Lateral subqueries can reference columns of tables defined outside the subquery at the same level, i.e. ''laterally''.
For example, a LATERAL subquery in a FROM clause could reference tables defined in the same FROM clause.
Currently only the columns of tables defined ''above'' subqueries are recognized.
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00292.php <nowiki>LATERAL</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-10/msg00991.php <nowiki>Re: LATERAL</nowiki>]
* [http://archives.postgresql.org/message-id/4F5AA202.9020906@gmail.com lateral function as a subquery - WIP patch]
}}

{{TodoItem
|Prevent temporary tables created with ON COMMIT DELETE ROWS from repeatedly truncating the table on every commit if the table is already empty
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00842.php
* http://archives.postgresql.org/pgsql-performance/2010-03/msg00392.php
* http://archives.postgresql.org/pgsql-performance/2010-04/msg00046.php
}}

{{TodoItem
|Allow DELETE and UPDATE to be used with LIMIT and ORDER BY
* http://archives.postgresql.org/pgadmin-hackers/2010-04/msg00078.php
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg01997.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00021.php
}}

{{TodoItem
|Allow PREPARE of cursors}}

{{TodoItem
|Have DISCARD PLANS discard plans cached by functions
|DISCARD all should do the same.
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00431.php
}}

{{TodoItem
|Avoid multiple-evaluation of BETWEEN and IN arguments containing volatile expressions
* http://archives.postgresql.org/message-id/4D95B605.2020709@enterprisedb.com
}}

{{TodoItem
|Fix nested CASE-WHEN constructs
* http://archives.postgresql.org/message-id/4DDCEEB8.50602@enterprisedb.com
}}

=== CREATE ===
{{TodoSubsection}}

{{TodoItem
|Allow CREATE TABLE AS to determine column lengths for complex expressions like SELECT col1 || col2}}

{{TodoItem
|Have WITH CONSTRAINTS also create constraint indexes
* [http://archives.postgresql.org/pgsql-patches/2007-04/msg00149.php <nowiki>Re: CREATE TABLE LIKE INCLUDING INDEXES support</nowiki>]
}}

{{TodoItem
|Move NOT NULL constraint information to pg_constraint
|Currently NOT NULL constraints are stored in pg_attribute without any designation of their origins, e.g. primary keys. One manifest problem is that dropping a PRIMARY KEY constraint does not remove the NOT NULL constraint designation. Another issue is that we should probably force NOT NULL to be propagated from parent tables to children, just as CHECK constraints are. (But then does dropping PRIMARY KEY affect children?)
* http://archives.postgresql.org/message-id/19768.1238680878@sss.pgh.pa.us
* http://archives.postgresql.org/message-id/200909181005.n8IA5Ris061239@wwwmaster.postgresql.org
* http://archives.postgresql.org/pgsql-hackers/2011-07/msg01223.php
* http://archives.postgresql.org/pgsql-hackers/2011-07/msg00358.php
}}

{{TodoItem
|Prevent concurrent CREATE TABLE from sometimes returning a cryptic error message
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00169.php <nowiki>BUG #3692: Conflicting create table statements throw unexpected error</nowiki>]
}}

{{TodoItem
|Add CREATE SCHEMA ... LIKE that copies a schema}}

{{TodoItem
|Fix CREATE OR REPLACE FUNCTION to not leave objects depending on the function in inconsistent state
* [http://archives.postgresql.org/pgsql-general/2008-08/msg00985.php indexes on functions and create or replace function]
}}

{{TodoItem
|Allow temporary tables to exist as empty by default in all sessions
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00006.php <nowiki>what is difference between LOCAL and GLOBAL TEMP TABLES in PostgreSQL</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg01329.php <nowiki>idea: global temp tables</nowiki>]
* [http://archives.postgresql.org//pgsql-hackers/2009-05/msg00016.php <nowiki>Re: idea: global temp tables</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg01098.php <nowiki>global temporary tables</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2012-04/msg01148.php Temporary tables under hot standby]
}}

{{TodoItem
|Allow the creation of "distinct" types
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01647.php <nowiki>Distinct types</nowiki>]
}}

{{TodoItem
|Consider analyzing temporary tables when they are first used in a query
|Autovacuum cannot analyze or vacuum temporary tables.
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00416.php <nowiki>autovacuum and temp tables support</nowiki>]
}}

{{TodoItem
|Allow an unlogged table to be changed to logged
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00315.php
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00437.php
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00323.php
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00237.php
}}

{{TodoEndSubsection}}

=== UPDATE ===
{{TodoSubsection}}

{{TodoItem
|<nowiki>Allow UPDATE tab SET ROW (col, ...) = (SELECT...)</nowiki>
* [http://archives.postgresql.org/pgsql-hackers/2006-07/msg01308.php <nowiki>Re: [PATCHES] extension for sql update</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00865.php <nowiki>UPDATE using sub selects</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-04/msg00315.php <nowiki>UPDATE using sub selects</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-03/msg00237.php <nowiki>Re: UPDATE using sub selects</nowiki>]
}}

{{TodoItem
|Research self-referential UPDATEs that see inconsistent row versions in read-committed mode
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00507.php <nowiki>Concurrently updating an updatable view</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00016.php <nowiki>Re: Do we need a TODO? (was Re: Concurrently updating anupdatable view)</nowiki>]
}}

{{TodoItem
|Improve performance of EvalPlanQual mechanism that rechecks already-updated rows
|This is related to the previous item, which questions whether it even has the right semantics
* [http://archives.postgresql.org/pgsql-bugs/2008-09/msg00045.php <nowiki>BUG #4401: concurrent updates to a table blocks one update indefinitely</nowiki>]
* [http://archives.postgresql.org/pgsql-bugs/2009-07/msg00302.php <nowiki>BUG #4945: Parallel update(s) gone wild</nowiki>]
}}

{{TodoEndSubsection}}

=== ALTER ===
{{TodoSubsection}}

{{TodoItem
|Have ALTER TABLE RENAME of a SERIAL column rename the sequence
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]
* [http://archives.postgresql.org/message-id/CADLWmXUV4LbLhMZL8rYMhCy72aZZLB5BSARPQVgoX0BrxA0FFg@mail.gmail.com renaming implicit sequences]
}}

{{TodoItem
|Have ALTER SEQUENCE RENAME rename the sequence name stored in the sequence table
* [http://archives.postgresql.org/pgsql-bugs/2007-09/msg00092.php <nowiki>BUG #3619: Renaming sequence does not update its 'sequence_name' field</nowiki>]
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00007.php <nowiki>Re: BUG #3619: Renaming sequence does not update its 'sequence_name' field</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]
}}

{{TodoItem
|Add ALTER DOMAIN to modify the underlying data type}}

{{TodoItem
|Allow ALTER TABLESPACE to move the tablespace to different directories}}

{{TodoItem
|Allow moving system tables to other tablespaces, where possible
|Currently non-global system tables must be in the default database tablespace. Global system tables can never be moved.}}

{{TodoItem
|Have ALTER INDEX update the name of a constraint using that index}}

{{TodoItem
|Allow column display reordering by recording a display, storage, and permanent id for every column?
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00782.php <nowiki>Re: column ordering, was Re: [PATCHES] Enums patch v2</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg01029.php <nowiki>Column reordering in pg_dump</nowiki>]
* http://archives.postgresql.org/message-id/1324412114-sup-9608@alvh.no-ip.org
}}

{{TodoItem
|Allow deactivating (and reactivating) indexes via ALTER TABLE
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg01191.php
}}

{{TodoItem
|Add ALTER OPERATOR ... RENAME
|needs to consider effects of changing operator precedence
* [http://archives.postgresql.org/message-id/1322948781.26266.9.camel@vanquo.pezone.net Missing rename support]
}}

{{TodoItem
|Add ALTER TABLE ... RENAME RULE
* [http://archives.postgresql.org/message-id/1322948781.26266.9.camel@vanquo.pezone.net Missing rename support]
}}

{{TodoEndSubsection}}

=== CLUSTER ===
{{TodoSubsection}}

{{TodoItem
|Automatically maintain clustering on a table
|This might require some background daemon to maintain clustering during periods of low usage. It might also require tables to be only partially filled for easier reorganization. Another idea would be to create a merged heap/index data file so an index lookup would automatically access the heap data too. A third idea would be to store heap rows in hashed groups, perhaps using a user-supplied hash function.
* [http://archives.postgresql.org/pgsql-performance/2004-08/msg00350.php <nowiki>Equivalent praxis to CLUSTERED INDEX?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00155.php <nowiki>Re: Grouped Index Tuples</nowiki>]
* http://community.enterprisedb.com/git/
* [http://archives.postgresql.org/pgsql-performance/2009-10/msg00346.php <nowiki>Re: maintain_cluster_order_v5.patch</nowiki>]
}}

{{TodoEndSubsection}}

=== COPY ===
{{TodoSubsection}}

{{TodoItem
|Allow COPY to report error lines and continue
|This requires the use of a savepoint before each COPY line is processed, with ROLLBACK on COPY failure.
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00572.php <nowiki>Re: VLDB Features</nowiki>]
}}

{{TodoItem
|Allow COPY FROM to create index entries in bulk
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00811.php <nowiki>Batch update of indexes on data loading</nowiki>]
}}

{{TodoItem
|Allow COPY in CSV mode to control whether a quoted zero-length string is treated as NULL
|Currently this is always treated as a zero-length string, which generates an error when loading into an integer column
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00905.php <nowiki>Re: [PATCHES] allow CSV quote in NULL</nowiki>]
}}

{{TodoItem
|Improve COPY performance
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00954.php <nowiki>Re: 8.3 / 8.2.6 restore comparison</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01882.php
}}

{{TodoItem
|Allow COPY to report errors sooner
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01169.php <nowiki>Timely reporting of COPY errors</nowiki>]
}}

{{TodoItem
|Allow COPY to handle other number formats
|E.g. the German notation. Best would be something like WITH DECIMAL ','.
}}

{{TodoItem
|Allow a stalled COPY to exit if the backend is terminated
* [http://archives.postgresql.org/pgsql-bugs/2009-04/msg00067.php <nowiki>Re: possible bug not in open items</nowiki>]
}}

{{TodoEndSubsection}}

=== GRANT/REVOKE ===
{{TodoSubsection}}

{{TodoItem
|Allow SERIAL sequences to inherit permissions from the base table?}}

{{TodoItem
|Allow dropping of a role that has connection rights
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00736.php <nowiki>DROP ROLE dependency tracking ...</nowiki>]
}}
{{TodoEndSubsection}}

=== DECLARE CURSOR ===
{{TodoSubsection}}

{{TodoItem
|Prevent DROP TABLE from dropping a table referenced by its own open cursor?}}

{{TodoItem
|Provide some guarantees about the behavior of cursors that invoke volatile functions
* [http://archives.postgresql.org/message-id/20997.1244563664@sss.pgh.pa.us Re: Cursor with hold emits the same row more than once across commits in 8.3.7]
}}

{{TodoEndSubsection}}

=== INSERT ===
{{TodoSubsection}}

{{TodoItem
|Allow INSERT/UPDATE of the system-generated oid value for a row}}

{{TodoItemDone
|In rules, allow VALUES() to contain a mixture of 'old' and 'new' references}}

{{TodoEndSubsection}}

=== SHOW/SET ===
{{TodoSubsection}}

{{TodoItem
|Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM ANALYZE, and CLUSTER}}

{{TodoItem
|Rationalize the discrepancy between settings that use values in bytes and SHOW that returns the object count
* [http://archives.postgresql.org/pgsql-docs/2008-07/msg00007.php <nowiki>Re: [ADMIN] shared_buffers and shmmax</nowiki>]
}}

{{TodoEndSubsection}}

=== ANALYZE ===
{{TodoSubsection}}

{{TodoItem
|Have EXPLAIN ANALYZE issue NOTICE messages when the estimated and actual row counts differ by a specified percentage}}

{{TodoItem
|Have EXPLAIN ANALYZE report rows as floating-point numbers
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg01363.php <nowiki>explain analyze rows=%.0f</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00108.php <nowiki>Re: explain analyze rows=%.0f</nowiki>]
}}

{{TodoItem
|Improve how ANALYZE computes in-doubt tuples
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00771.php <nowiki>VACUUM/ANALYZE counting of in-doubt tuples</nowiki>]
}}

{{TodoEndSubsection}}

=== Window Functions ===
See {{messageLink|357.1230492361@sss.pgh.pa.us|TODO items for window functions}}.
{{TodoSubsection}}
{{TodoItem
|Support creation of user-defined window functions
|We have the ability to create new window functions written in C. Is it
worth the effort to create an API that would let them be written in PL/pgsql, etc?}}

{{TodoItem
|Implement full support for window framing clauses
|In addition to done clauses described in the [http://developer.postgresql.org/pgdocs/postgres/sql-expressions.html#SYNTAX-WINDOW-FUNCTIONS latest doc], these clauses are not implemented yet.
* RANGE BETWEEN ... PRECEDING/FOLLOWING
* EXCLUDE
}}

{{TodoItem
|Investigate tuplestore performance issues
|The tuplestore_in_memory() thing is just a band-aid, we ought to try to solve it properly. tuplestore_advance seems like a weak spot as well.
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00152.php <nowiki>tuplestore potential performance problem</nowiki>]
}}

{{TodoItem|Do we really need so much duplicated code between Agg and WindowAgg?}}

{{TodoItem
|Teach planner to evaluate multiple windows in the optimal order
|Currently windows are always evaluated in the query-specified order.
* http://archives.postgresql.org/message-id/3CDAD71E9D70417290FCF66F0178D1E1@amd64
}}

{{TodoItem
|Implement DISTINCT clause in window aggregates
|Some proprietary RDBMSs have implemented it already, so it helps with porting from those.}}

{{TodoEndSubsection}}

== Integrity Constraints ==
=== Keys ===

{{TodoSubsection}}

{{TodoItem
|Improve deferrable unique constraints for cases with many conflicts
|The current implementation fires a trigger for each potentially conflicting row. This might not scale well for an update that changes many key values at once.
}}

{{TodoEndSubsection}}

=== Referential Integrity ===
{{TodoSubsection}}

{{TodoItem
|Add MATCH PARTIAL referential integrity}}

{{TodoItem
|Change foreign key constraint for array -> element to mean element in array?
* [http://archives.postgresql.org/pgsql-hackers/2010-10/msg01814.php <nowiki>foreign keys for array/period contains relationships</nowiki>]
}}

{{TodoItem
|Fix problem when cascading referential triggers make changes on cascaded tables, seeing the tables in an intermediate state
* [http://archives.postgresql.org/pgsql-hackers/2005-09/msg00174.php <nowiki>Re: [PATCHES] Work-in-progress referential action trigger timing</nowiki>]
}}

{{TodoItem
|Are ri_KeysEqual checks in the RI enforcement triggers still necessary?
* [http://archives.postgresql.org/pgsql-performance/2005-10/msg00458.php <nowiki>Re: Effects of cascading references in foreign keys</nowiki>]
}}

{{TodoItemDone
|Optimize referential integrity checks involving null values
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00744.php <nowiki>Can't ri_KeysEqual() consider two nulls as equal?</nowiki>]
}}

{{TodoEndSubsection}}

=== Check Constraints ===
{{TodoSubsection}}

{{TodoItem
|Run check constraints only when affected columns are changed
* http://archives.postgresql.org/message-id/1326055327.15293.13.camel@vanquo.pezone.net
}}

{{TodoEndSubsection}}

== Server-Side Languages ==

{{TodoItem
|Add support for polymorphic arguments and return types to languages other than PL/PgSQL}}

{{TodoItem
|Add support for OUT and INOUT parameters to languages other than PL/PgSQL}}

{{TodoItem
|Add more fine-grained specification of functions taking arbitrary data types
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00367.php <nowiki>RfD: more powerful "any" types</nowiki>]
}}

{{TodoItem
|Implement stored procedures
|This might involve the control of transaction state and the return of multiple result sets
* [http://archives.postgresql.org/pgsql-general/2008-10/msg00454.php <nowiki>PL/pgSQL stored procedure returning multiple result sets (SELECTs)?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01375.php <nowiki>Proposal: real procedures again (8.4)</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg00542.php
* [http://archives.postgresql.org/pgsql-hackers/2011-04/msg01149.php <nowiki>Gathering specs and discussion on feature (post 9.1)</nowiki>]
}}

{{TodoItem
|Allow holdable cursors in SPI}}

{{TodoItemEasy
|Add SPI_gettypmod() to return a field's typemod from a TupleDesc
* http://archives.postgresql.org/pgsql-hackers/2005-11/msg00250.php
}}

=== SQL-Language Functions ===
{{TodoSubsection}}

{{TodoItem
|Rethink query plan caching and timing of parse analysis within SQL-language functions
|They should work more like plpgsql functions do ...
* [http://archives.postgresql.org/pgsql-bugs/2011-05/msg00078.php <nowiki>Re: BUG #6019: invalid cached plan on inherited table</nowiki>]
}}

{{TodoEndSubsection}}

=== PL/pgSQL ===
{{TodoSubsection}}

{{TodoItem
|Allow handling of %TYPE arrays, e.g. tab.col%TYPE[]}}

{{TodoItem
|<nowiki>Allow listing of record column names, and access to record columns via variables, e.g. columns := r.(*), tval2 := r.(colname)</nowiki>
* [http://archives.postgresql.org/pgsql-patches/2005-07/msg00458.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2006-05/msg00302.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00031.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]
}}

{{TodoItem
|Allow row and record variables to be set to NULL constants, and allow NULL tests on such variables
|Because a row is not scalar, do not allow assignment from NULL-valued scalars.
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg00070.php <nowiki>NULL and plpgsql rows</nowiki>]
}}

{{TodoItem
|Consider keeping separate cached copies when search_path changes
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg01009.php <nowiki>pl/pgsql Plan Invalidation and search_path</nowiki>]
}}

{{TodoItem
|Improve handling of NULL row values vs. NULL rows
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01758.php <nowiki>Null row vs. row of nulls in plpgsql</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg01973.php
}}

{{TodoItem
|Improve PERFORM handling of WITH queries or document limitation
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00309.php
}}

{{TodoEndSubsection}}

=== PL/Perl ===
{{TodoSubsection}}

{{TodoItem
|Allow regex operations in plperl using UTF8 characters in non-UTF8 encoded databases}}

{{TodoEndSubsection}}

=== PL/Python ===
{{TodoSubsection}}

{{TodoItem
|Develop a trusted variant of PL/Python.}}

{{TodoItem
|Create a new restricted execution class that will allow passing function arguments in as locals. Passing them as globals means functions cannot be called recursively.
* [http://archives.postgresql.org/pgsql-hackers/2011-02/msg01468.php <nowiki>Re: pl/python do not delete function arguments</nowiki>]
}}

{{TodoItem
|Add a DB-API compliant interface on top of the SPI interface
* http://petereisentraut.blogspot.com/2011/11/plpydbapi-db-api-for-plpython.html
}}

{{TodoItem
|For functions returning a setof record with a composite type, cache the I/O functions for the composite type
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg02007.php
}}

{{TodoItem
|Fix loss of information during conversion of numeric type to Python float}}

{{TodoEndSubsection}}

=== PL/Tcl ===
{{TodoSubsection}}

{{TodoItem
|Add table function support}}

{{TodoItem
|Check encoding validity of values passed back to Postgres in function returns, trigger tuple changes, and SPI calls.}}

{{TodoEndSubsection}}

== Clients ==

{{TodoItem
|Add a function like pg_get_indexdef() that report more detailed index information
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00166.php <nowiki>BUG #3829: Wrong index reporting from pgAdmin III (v1.8.0 rev 6766-6767)</nowiki>]
}}

{{TodoItem
|Split out pg_resetxlog output into pre- and post-sections
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg02040.php
}}

=== pg_ctl ===
{{TodoSubsection}}

{{TodoItem
|Improve pg_ctl's detection of running postmasters
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00000.php
* http://archives.postgresql.org/pgsql-committers/2011-06/msg00001.php
}}

{{TodoItem
|Add additional shutdown modes, and change the default?
* http://archives.postgresql.org/pgsql-hackers/2012-04/msg01283.php
}}

{{TodoEndSubsection}}

=== psql ===
{{TodoSubsection}}

{{TodoItem
|Have psql \ds show all sequences and their settings
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00916.php <nowiki>Re: TODO item: Have psql show current values for a sequence</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00401.php <nowiki>Quick patch: Display sequence owner</nowiki>]
}}

{{TodoItem
|Move psql backslash database information into the backend, use mnemonic commands?
|This would allow non-psql clients to pull the same information out of the database as psql.
* [http://archives.postgresql.org/pgsql-hackers/2004-01/msg00191.php <nowiki>Re: psql \d option list overloaded</nowiki>]
}}

{{TodoItem
|Make psql's \d commands more consistent in their handling of schemas
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00014.php <nowiki>Re: psql and schemas</nowiki>]
}}

{{TodoItem
|Make psql's \d commands distinguish default privileges from no privileges
|ACL displays were visibly different for the two cases before we "improved" them by using array_to_string.
* [http://archives.postgresql.org/pgsql-bugs/2011-05/msg00082.php <nowiki>BUG #6021: There is no difference between default and empty access privileges with \dp</nowiki>]
}}

{{TodoItem
|Consistently display privilege information for all objects in psql}}

{{TodoItemEasy
|\s without arguments (display history) fails with libedit, doesn't use pager either
* [http://archives.postgresql.org/pgsql-bugs/2011-06/msg00114.php <nowiki> psql \s not working - OS X</nowiki>]
}}

{{TodoItem
|Add a \set variable to control whether \s displays line numbers
|Another option is to add \# which lists line numbers, and allows command execution.
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php <nowiki>Re: psql possible TODO</nowiki>]
}}

{{TodoItem
|Include the symbolic SQLSTATE name in verbose error reports
* [http://archives.postgresql.org/pgsql-general/2007-09/msg00438.php <nowiki>Re: Checking is TSearch2 query is valid</nowiki>]
}}

{{TodoItem
|Add prompt escape to display the client and server versions
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00310.php <nowiki>WIP patch for TODO Item: Add prompt escape to display the client and server versions</nowiki>]
}}

{{TodoItem
|Add option to wrap column values at whitespace boundaries, rather than chopping them at a fixed width.
|Currently, "wrapped" format chops values into fixed widths. Perhaps the word wrapping could use the same algorithm documented in the W3C specification.
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00404.php <nowiki>Re: psql wrapped format default for backslash-d commands</nowiki>]
* http://www.w3.org/TR/CSS21/tables.html#auto-table-layout}}

{{TodoItem
|Support the ReST table output format
|Details about the ReST format: http://docutils.sourceforge.net/rst.html#reference-documentation
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg01007.php <nowiki>Proposal: new border setting in psql</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00518.php <nowiki>Re: Proposal: new border setting in psql</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00609.php <nowiki>Re: Proposal: new border setting in psql</nowiki>]
}}

{{TodoItem
|Add option to print advice for people familiar with other databases
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg01845.php <nowiki>MySQL-ism help patch for psql</nowiki>]
}}

{{TodoItem
|Add ability to edit views with \ev
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00023.php <nowiki>Adding \ev view editor?</nowiki>]
}}

{{TodoItem
|Fix FETCH_COUNT to handle SELECT ... INTO and WITH queries
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01565.php
* http://archives.postgresql.org/pgsql-bugs/2010-05/msg00192.php
}}

{{TodoItem
|Prevent psql from sending remaining single-line multi-statement queries after reconnecting
* http://archives.postgresql.org/pgsql-bugs/2010-05/msg00159.php
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01283.php
}}

{{TodoItemEasy
|Add \i option to bring in the specified file as a quoted literal
|This would be useful for creating functions and other areas. Details still need to be worked out.
* http://archives.postgresql.org/pgsql-bugs/2011-02/msg00016.php
* http://archives.postgresql.org/pgsql-bugs/2011-02/msg00020.php
}}

{{TodoItem
|Consider having psql -c read .psqlrc, for consistency
|psql -f already reads .psqlrc
}}

{{TodoItem
|Allow processing of multiple -f (file) options
}}

{{TodoItem
|Improve line drawing characters
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00386.php
}}

{{TodoItem
|Consider improving the continuation prompt
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01772.php
}}

{{TodoItem
|Improve speed of tab completion by using LIKE
* http://www.postgresql.org/message-id/20121012060345.GA29214@toroid.org
}}

{{TodoEndSubsection}}

=== pg_dump / pg_restore ===
{{TodoSubsection}}

{{TodoItemEasy
|<nowiki>Add full object name to the tag field. eg. for operators we need '=(integer, integer)', instead of just '='.</nowiki>}}

{{TodoItem
|Add pg_dumpall custom format dumps?
* [http://archives.postgresql.org/pgsql-general/2010-05/msg00509.php pg_dumpall custom format]
|}}

{{TodoItem
|Avoid using platform-dependent locale names in pg_dumpall output
|Using native locale names puts roadblocks in the way of porting a dump to another platform. One possible solution is to get
CREATE DATABASE to accept some agreed-on set of locale names and fix them up to meet the platform's requirements.
* http://archives.postgresql.org/message-id/21396.1241716688@sss.pgh.pa.us
}}

{{TodoItem
|Allow selection of individual object(s) of all types, not just tables}}

{{TodoItem
|In a selective dump, allow dumping of an object and all its dependencies}}

{{TodoItem
|Add options like pg_restore -l and -L to pg_dump}}

{{TodoItemDone
|Add support for multiple pg_restore -t options, like pg_dump}}

{{TodoItem
|Stop dumping CASCADE on DROP TYPE commands in clean mode}}

{{TodoItem
|Allow pg_dump --clean to drop roles that own objects or have privileges
|tgl says: if this is about pg_dumpall, it's done as of 8.4. If it's really about pg_dump, what does it mean? pg_dump has no business dropping roles.}}

{{TodoItem
|Allow pg_restore to load different parts of the COPY data for a single table simultaneously}}

{{TodoItem
|Remove support for dumping from pre-7.3 servers
|In 7.3 and later, we can get accurate dependency information from the server. pg_dump still contains a lot of crufty code
to try to deal with the lack of dependency info in older servers, but the usefulness of maintaining that code grows small.}}

{{TodoItem
|Refactor handling of database attributes between pg_dump and pg_dumpall
|Currently only pg_dumpall emits database attributes, such as ALTER DATABASE SET commands and database-level GRANTs.
Many people wish that pg_dump would do that. One proposal is to let pg_dump issue such commands if the -C switch was used,
but it's unclear whether that will satisfy the demand.
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg01031.php <nowiki>ALTER DATABASE vs pg_dump</nowiki>]
* [http://archives.postgresql.org/pgsql-bugs/2010-05/msg00010.php summary of the issues]
}}

{{TodoItem
|Change pg_dump so that a comment on the dumped database is applied to the loaded database, even if the database has a different name.
|This will require new backend syntax, perhaps COMMENT ON CURRENT DATABASE. This is related to the previous item.}}

{{TodoItem
|Allow parallel restore of tar dumps
* [http://archives.postgresql.org/pgsql-hackers/2009-02/msg01154.php <nowiki>Re: parallel restore</nowiki>]
}}

{{TodoItem
|Preserve sparse storage of large objects over dump/restore
* [http://archives.postgresql.org/message-id/18789.1349750451@sss.pgh.pa.us <nowiki>TODO item: teach pg_dump about sparsely-stored large objects</nowiki>]
}}

{{TodoEndSubsection}}

=== ecpg ===
{{TodoSubsection}}

{{TodoItem
|Docs
|Document differences between ecpg and the SQL standard and information about the Informix-compatibility module.}}

{{TodoItem
|Solve cardinality > 1 for input descriptors / variables?}}

{{TodoItem
|Add a semantic check level, e.g. check if a table really exists}}

{{TodoItem
|fix handling of DB attributes that are arrays}}

{{TodoItem
|Fix nested C comments}}

{{TodoItemEasy
|sqlwarn[6] should be 'W' if the PRECISION or SCALE value specified}}

{{TodoItem
|Make SET CONNECTION thread-aware, non-standard?}}

{{TodoItem
|Allow multidimensional arrays}}

{{TodoItem
|Implement COPY FROM STDIN}}

{{TodoItem
|Provide a way to specify size of a bytea parameter
* [http://archives.postgresql.org/message-id/200906192131.n5JLVoMo044178@wwwmaster.postgresql.org <nowiki>BUG #4866: ECPG and BYTEA</nowiki>]
}}

{{TodoItemEasy
|Fix small memory leaks in ecpg
|Memory leaks in a short running application like ecpg are not really a problem, but make debugging more complicated}}

{{TodoItem
|Allow reuse of cursor name variables
* [http://archives.postgresql.org/message-id/20100329113435.GA3430@feivel.credativ.lan <nowiki>Problems with variable cursorname in ecpg</nowiki>]
}}

{{TodoEndSubsection}}

=== libpq ===
{{TodoSubsection}}

{{TodoItem
|Prevent PQfnumber() from lowercasing unquoted column names
|PQfnumber() should never have been doing lowercasing, but historically it has so we need a way to prevent it}}

{{TodoItem
|Consider disallowing multiple queries in PQexec() as an additional barrier to SQL injection attacks
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg00184.php <nowiki>Re: InitPostgres and flatfiles question</nowiki>]
}}

{{TodoItem
|Add PQexecf() that allows complex parameter substitution
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01803.php <nowiki>Last minute mini-proposal (I know, know) for PQexecf()</nowiki>]
}}

{{TodoItem
|Add SQLSTATE and severity to errors generated within libpq itself
* [http://archives.postgresql.org/pgsql-interfaces/2007-11/msg00015.php <nowiki>v8.1: Error severity on libpq PGconn*</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01425.php
}}

{{TodoItem
|Add support for interface/ipaddress binding to libpq
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01811.php <nowiki>SR/libpq - outbound interface/ipaddress binding</nowiki>]
}}

{{TodoEndSubsection}}

=== HTTP===
{{TodoSubsection}}

{{TodoItem
|Allow access to the database via HTTP
|See [[HTTP_API]]}}

{{TodoEndSubsection}}

== Triggers ==

{{TodoItem
|Improve storage of deferred trigger queue
|Right now all deferred trigger information is stored in backend memory. This could exhaust memory for very large trigger queues. This item involves dumping large queues into files, or doing some kind of join to process all the triggers, some bulk operation, or a bitmap.
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00876.php <nowiki>Re: BUG #4204: COPY to table with FK has memory leak</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-10/msg00464.php <nowiki>Scaling up deferred unique checks and the after trigger queue</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2011-08/msg00023.php
}}

{{TodoItem
|Allow triggers to be disabled in only the current session.
|This is currently possible by starting a multi-statement transaction, modifying the system tables, performing the desired SQL, restoring the system tables, and committing the transaction. ALTER TABLE ... TRIGGER requires a table lock so it is not ideal for this usage.}}

{{TodoItem
|With disabled triggers, allow pg_dump to use ALTER TABLE ADD FOREIGN KEY
|If the dump is known to be valid, allow foreign keys to be added without revalidating the data.}}

{{TodoItem
|Allow statement-level triggers to access modified rows}}

{{TodoItem
|When statement-level triggers are defined on a parent table, have them fire only on the parent table, and fire child table triggers only where appropriate
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg01883.php <nowiki>Statement-level triggers and inheritance</nowiki>]
}}

{{TodoItemDone
|Add event triggers
}}

{{TodoItem
|Tighten trigger permission checks
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00564.php <nowiki>Security leak with trigger functions?</nowiki>]
}}

{{TodoItem
|Allow BEFORE INSERT triggers on views
* [http://archives.postgresql.org/pgsql-general/2007-02/msg01466.php <nowiki>Re: Why can't I put a BEFORE EACH ROW trigger on a view?</nowiki>]
}}

{{TodoItem
|Add database and transaction-level triggers
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00451.php <nowiki>Proposal for db level triggers</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00620.php <nowiki>triggers on prepare, commit, rollback... ?</nowiki>]
}}

{{TodoItem
|Reduce locking requirements for creating a trigger
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00635.php <nowiki>Re: Change lock requirements for adding a trigger</nowiki>]
}}

{{TodoItem
|Avoid requirement for "AFTER" trigger functions to return a value
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02384.php
}}

{{TodoItem
|Allow creation of inline triggers
* http://archives.postgresql.org/pgsql-hackers/2012-02/msg00708.php
}}

== Inheritance ==

{{TodoItem
|Allow inherited tables to inherit indexes, UNIQUE constraints, and primary/foreign keys
* [http://archives.postgresql.org/pgsql-hackers/2010-05/msg00285.php <nowiki>Partitioning/inherited tables vs FKs</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00039.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00305.php
}}

{{TodoItem
|Honor UNIQUE INDEX on base column in INSERTs/UPDATEs on inherited table, e.g. INSERT INTO inherit_table (unique_index_col) VALUES (dup) should fail
|The main difficulty with this item is the problem of creating an index that can span multiple tables.}}

{{TodoItem
|Determine whether ALTER TABLE / SET SCHEMA should work on inheritance hierarchies (and thus support ONLY). If yes, implement it.}}

{{TodoItem
|ALTER TABLE variants sometimes support recursion and sometimes not, but this is poorly/not documented, and the ONLY marker would then be silently ignored. Clarify the documentation, and reject ONLY if it is not supported.}}

== Indexes ==

{{TodoItem
|Prevent index uniqueness checks when UPDATE does not modify the column
|Uniqueness (index) checks are done when updating a column even if the column is not modified by the UPDATE.
However, HOT already short-circuits this in common cases, so more work might not be helpful.}}

{{TodoItem
|Allow the creation of on-disk bitmap indexes which can be quickly combined with other bitmap indexes
|Such indexes could be more compact if there are only a few distinct values. Such indexes can also be compressed. Keeping such indexes updated can be costly.
* [http://archives.postgresql.org/pgsql-patches/2005-07/msg00512.php <nowiki>Re: Bitmap index AM</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg01107.php <nowiki>Bitmap index thoughts</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00265.php <nowiki>Stream bitmaps</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01214.php <nowiki>Re: Bitmapscan changes - Requesting further feedback</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00013.php <nowiki>Updated bitmap index patch</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00741.php <nowiki>Reviewing new index types (was Re: [PATCHES] Updated bitmap indexpatch)</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01023.php <nowiki>Bitmap Indexes: request for feedback</nowiki>]
* http://archives.postgresql.org/message-id/800923.27831.qm@web29010.mail.ird.yahoo.com
}}

{{TodoItem
|Allow accurate statistics to be collected on indexes with more than one column or expression indexes, perhaps using per-index statistics
* [http://archives.postgresql.org/pgsql-performance/2006-10/msg00222.php <nowiki>Re: Simple join optimized badly?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01131.php <nowiki>Stats for multi-column indexes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00741.php <nowiki>Cross-column statistics revisited</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg01431.php <nowiki>Multi-Dimensional Histograms</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00913.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg02179.php
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00459.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02054.php
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01731.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00894.php
* http://archives.postgresql.org/pgsql-hackers/2011-09/msg00679.php
}}

{{TodoItem
|Consider having a larger statistics target for indexed columns and expression indexes.
}}

{{TodoItem
|Consider smaller indexes that record a range of values per heap page, rather than having one index entry for every heap row
|This is useful if the heap is clustered by the indexed values.
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00341.php <nowiki>Grouped Index Tuples</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg01264.php <nowiki>Grouped Index Tuples</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00465.php <nowiki>Grouped Index Tuples / Clustered Indexes</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-03/msg00163.php <nowiki>Bitmapscan changes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00014.php <nowiki>Re: GIT patch</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00487.php <nowiki>Re: Index Tuple Compression Approach?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01589.php <nowiki>Re: Index AM change proposals, redux</nowiki>]
}}

{{TodoItem
|Add REINDEX CONCURRENTLY, like CREATE INDEX CONCURRENTLY
|This is difficult because you must upgrade to an exclusive table lock to replace the existing index file. CREATE INDEX CONCURRENTLY does not have this complication. This would allow index compaction without downtime.
* [http://archives.postgresql.org/pgsql-performance/2007-08/msg00289.php <nowiki>Re: When/if to Reindex</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2012-09/msg00911.php
* http://archives.postgresql.org/pgsql-hackers/2012-10/msg00128.php
}}

{{TodoItem
|Allow multiple indexes to be created concurrently, ideally via a single heap scan
|pg_restore allows parallel index builds, but it is done via subprocesses, and there is no SQL interface for this.
Cluster could definitely benefit from this.
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00093.php
}}

{{TodoItem
|Consider sorting entries before inserting into btree index
* [http://archives.postgresql.org/pgsql-general/2008-01/msg01010.php <nowiki>Re: ATTN: Clodaldo was Performance problem. Could it be related to 8.3-beta4?</nowiki>]
}}

{{TodoItem
|Allow creation of an index that can do comparisons to test if a value is between two column values
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00757.php <nowiki>Proposal: temporal extension "period" data type</nowiki>]
}}

{{TodoItem
|Consider using "effective_io_concurrency" for index scans
* Currently only bitmap scans use this, which might be fine because most multi-row index scans use bitmap scans.
}}

{{TodoItem
|Fix problem with btree page splits during checkpoints
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00052.php
* http://archives.postgresql.org/pgsql-hackers/2011-09/msg00184.php
}}

{{TodoItem
|[http://archives.postgresql.org/pgsql-hackers/2012-05/msg00669.php Support amgettuple() in GIN (useful for exclusion constraints)]
}}

{{TodoItem
| Allow "loose" or "skip" scans on btree indexes in which the first column has low cardinality
* http://archives.postgresql.org/pgsql-performance/2012-08/msg00159.php
}}

=== GIST ===
{{TodoSubsection}}

{{TodoItem
|Add more GIST index support for geometric data types}}

{{TodoItem
|Allow GIST indexes to create certain complex index types, like digital trees (see Aoki)}}

{{TodoItem
|Fix performance issues in contrib/seg and contrib/cube GiST support
* [http://archives.postgresql.org/message-id/alpine.DEB.2.00.0904161633160.4053@aragorn.flymine.org GiST index performance]
* [http://archives.postgresql.org/message-id/alpine.DEB.2.00.0904221704470.22330@aragorn.flymine.org draft patch]
* [http://archives.postgresql.org/pgsql-performance/2009-05/msg00069.php <nowiki>Re: GiST index performance</nowiki>]
* [http://archives.postgresql.org/pgsql-performance/2009-06/msg00068.php <nowiki>GiST index performance</nowiki>]
}}

{{TodoItem
|[http://archives.postgresql.org/message-id/4DC8D284-05CF-4E3D-9670-AC9A32C37A36@justatheory.com GiST index support for arrays]
}}

{{TodoEndSubsection}}

=== Hash ===
{{TodoSubsection}}

{{TodoItem
|Add UNIQUE capability to hash indexes}}

{{TodoItem
|Add hash WAL logging for crash recovery
* http://archives.postgresql.org/pgsql-performance/2011-09/msg00196.php
}}

{{TodoItem
|Allow multi-column hash indexes}}

{{TodoEndSubsection}}

== Sorting ==

{{TodoItem
|Consider whether duplicate keys should be sorted by block/offset
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00558.php <nowiki>Remove hacks for old bad qsort() implementations?</nowiki>]
}}

{{TodoItem
|Consider being smarter about memory and external files used during sorts
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg01101.php <nowiki>Sorting Improvements for 8.4</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00045.php <nowiki>Re: Sorting Improvements for 8.4</nowiki>]
}}

{{TodoItem
|Consider detoasting keys before sorting}}

{{TodoItem
|Allow sorts to use more available memory
* http://archives.postgresql.org/pgsql-hackers/2007-11/msg01026.php
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg01123.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg01957.php
}}

== Fsync ==

{{TodoItem
|Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options and whether fsync does anything
|Ideally this requires a separate test program like /contrib/pg_test_fsync that can be run at initdb time or optionally later.
}}

{{TodoItem
|Consider sorting writes during checkpoint
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00541.php <nowiki>Sorted writes in checkpoint</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00050.php <nowiki>Re: Sorting writes during checkpoint</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg02012.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00278.php
* http://archives.postgresql.org/pgsql-hackers/2012-01/msg00493.php
}}

== Cache Usage ==

{{TodoItem
|Provide a way to calculate an "estimated COUNT(*)"
|Perhaps by using the optimizer's cardinality estimates or random sampling.
* [http://archives.postgresql.org/pgsql-hackers/2005-11/msg00943.php <nowiki>Re: Improving count(*)</nowiki>]
* http://wiki.postgresql.org/wiki/Slow_Counting
}}

{{TodoItem
|Consider automatic caching of statements at various levels:
* Parsed query tree
* Query execute plan
* Query results

:
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg00823.php <nowiki>Cached Query Plans (was: global prepared statements)</nowiki>]
}}

{{TodoItem
|Consider increasing internal areas (NUM_CLOG_BUFFERS) when shared buffers is increased
* [http://archives.postgresql.org/pgsql-hackers/2005-10/msg01419.php <nowiki>Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",)</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00030.php <nowiki>clog_buffers to 64 in 8.3?</nowiki>]
* [http://archives.postgresql.org/pgsql-performance/2007-08/msg00024.php <nowiki>CLOG Patch</nowiki>]
}}

{{TodoItem
|Consider decreasing the amount of memory used by PrivateRefCount
|
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg00797.php <nowiki>PrivateRefCount (for 8.3)</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg00752.php <nowiki>Re: PrivateRefCount (for 8.3)</nowiki>]
}}

{{TodoItem
|Consider allowing higher priority queries to have referenced buffer cache pages stay in memory longer
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00562.php <nowiki>Re: How to keep a table in memory?</nowiki>]
}}

{{TodoItem
|Improve cache lookup speed for sessions accessing many relations
* http://archives.postgresql.org/pgsql-hackers/2012-11/msg00356.php
}}

== Vacuum ==

{{TodoItem
|Auto-fill the free space map by scanning the buffer cache or by checking pages written by the background writer
* [http://archives.postgresql.org/pgsql-hackers/2006-02/msg01125.php <nowiki>Dead Space Map</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00011.php <nowiki>Re: Automatic free space map filling</nowiki>]
}}

{{TodoItem
|Allow concurrent inserts to use recently created pages rather than creating new ones
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg00853.php
}}

{{TodoItem
|Consider having single-page pruning update the visibility map
* <nowiki>https://commitfest.postgresql.org/action/patch_view?id=75</nowiki>
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg02344.php <nowiki>Re: visibility maps and heap_prune</nowiki>]
}}

{{TodoItem
|Improve tracking of total relation tuple counts now that vacuum doesn't always scan the whole heap
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00531.php Partial vacuum versus pg_class.reltuples]
}}

{{TodoItem
|Bias FSM towards returning free space near the beginning of the heap file, in hopes that empty pages at the end can be truncated by VACUUM
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg01124.php <nowiki>FSM search modes</nowiki>]
}}

{{TodoItem
|Consider a more compact data representation for dead tuple locations within VACUUM
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00143.php <nowiki>Re: Have vacuum emit a warning when it runs out of maintenance_work_mem</nowiki>]
}}

{{TodoItem
|Provide more information in order to improve user-side estimates of dead space bloat in relations
* [http://archives.postgresql.org/pgsql-general/2009-05/msg01039.php <nowiki>Re: Bloated Table</nowiki>]
}}

{{TodoItem
|Improve locking behaviour of vacuum during trailing page truncation
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00319.php
* http://archives.postgresql.org/message-id/4D8DF88E.7080205@Yahoo.com
}}

{{TodoItem
|Reduce the number of table scans performed by vacuum
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg01119.php
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00605.php
* http://archives.postgresql.org/pgsql-hackers/2011-07/msg00624.php
}}

{{TodoItem
|Vacuum Gin indexes in physically order rather than logical order
* http://archives.postgresql.org/pgsql-hackers/2012-04/msg00443.php
}}

{{TodoItem
|Avoid creation of the free space map for small tables
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg01751.php
* http://archives.postgresql.org/pgsql-hackers/2012-08/msg00552.php
* http://archives.postgresql.org/pgsql-hackers/2012-08/msg00615.php
}}

=== Auto-vacuum ===
{{TodoSubsection}}

{{TodoItemEasy
|Issue log message to suggest VACUUM FULL if a table is nearly empty?}}

{{TodoItem
|Prevent long-lived temporary tables from causing frozen-xid advancement starvation
|The problem is that autovacuum cannot vacuum them to set frozen xids; only the session that created them can do that.
* [http://archives.postgresql.org/pgsql-general/2007-06/msg01645.php <nowiki>Re: AutoVacuum Behaviour Question</nowiki>]
}}

{{TodoItem
|Prevent autovacuum from running if an old transaction is still running from the last vacuum
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00899.php <nowiki>Re: Autovacuum and OldestXmin</nowiki>]
}}

{{TodoItem
|Have autoanalyze of parent tables occur when child tables are modified
* http://archives.postgresql.org/pgsql-performance/2010-06/msg00137.php
* http://archives.postgresql.org/pgsql-performance/2010-10/msg00271.php
}}

{{TodoItem
|Allow visibility map all-visible bits to be set even when an auto-ANALYZE is running
* http://archives.postgresql.org/pgsql-hackers/2012-01/msg00356.php
}}

{{TodoItem
|Allow parallel cores to be used by vacuumdb
* [http://archives.postgresql.org/message-id/4F10A728.7090403@agliodbs.com vacuumdb -j]
}}

{{TodoItem
|Improve autovacuum tuning
* http://www.postgresql.org/message-id/5078AD6B.8060802@agliodbs.com
}}

{{TodoEndSubsection}}

== Locking ==

{{TodoItem
|Fix priority ordering of read and write light-weight locks
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00893.php <nowiki>lwlocks and starvation</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00905.php <nowiki>Re: lwlocks and starvation</nowiki>]
}}

{{TodoItem
|Fix problem when multiple subtransactions of the same outer transaction hold different types of locks, and one subtransaction aborts
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg01011.php <nowiki>FOR SHARE vs FOR UPDATE locks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00001.php <nowiki>Re: FOR SHARE vs FOR UPDATE locks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00435.php <nowiki>Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00773.php <nowiki>Re: savepoints and upgrading locks</nowiki>]
}}

{{TodoItem
|Allow UPDATEs on only non-referential integrity columns not to conflict with referential integrity locks
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00073.php <nowiki>Referential Integrity and SHARE locks</nowiki>]
}}

{{TodoItem
|Add idle_in_transaction_timeout GUC so locks are not held for long periods of time}}

{{TodoItem
|Improve deadlock detection when a page cleaning lock conflicts with a shared buffer that is pinned
* [http://archives.postgresql.org/pgsql-bugs/2008-01/msg00138.php <nowiki>BUG #3883: Autovacuum deadlock with truncate?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php <nowiki>Thoughts about bug #3883</nowiki>]
* [http://archives.postgresql.org/pgsql-committers/2008-01/msg00365.php <nowiki>Re: pgsql: Add checks to TRUNCATE, CLUSTER, and REINDEX to prevent</nowiki>]
}}

{{TodoItem
|Detect deadlocks involving LockBufferForCleanup()
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php <nowiki>Thoughts about bug #3883</nowiki>]
}}

{{TodoItem
|Allow finer control over who is cancelled in a deadlock
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01727.php
}}

{{TodoItem
|Consider a lock timeout parameter
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00485.php <nowiki>SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5</nowiki>]
}}

== Startup Time Improvements ==

{{TodoItem
|Experiment with multi-threaded backend for backend creation
|This would prevent the overhead associated with process creation. Most operating systems have trivial process creation time compared to database startup overhead, but a few operating systems (Win32, Solaris) might benefit from threading. Also explore the idea of a single session using multiple threads to execute a statement faster.}}

{{TodoItem
|Allow backends to change their database without restart
|This allows for faster server startup.
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00843.php
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00336.php
}}

== Write-Ahead Log ==

{{TodoItem
|Eliminate need to write full pages to WAL before page modification
|Currently, to protect against partial disk page writes, we write full page images to WAL before they are modified so we can correct any partial page writes during recovery. These pages can also be eliminated from point-in-time archive files.
* [http://archives.postgresql.org/pgsql-hackers/2002-06/msg00655.php <nowiki>Re: Index Scans become Seq Scans after VACUUM ANALYSE</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg01191.php
* [http://archives.postgresql.org/message-id/20120105061916.GB21048@fetter.org WIP double writes]
* [http://archives.postgresql.org/message-id/4EFC449F02000025000441CD@gw.wicourts.gov double writes]
* [http://archives.postgresql.org/message-id/20120110214344.GB21106@fetter.org Double-write with Fast Checksums]
* [http://archives.postgresql.org/message-id/1962493974.656458.1327703514780.JavaMail.root@zimbra-prod-mbox-4.vmware.com double writes using "double-write buffer" approach]
* http://archives.postgresql.org/pgsql-hackers/2012-10/msg01463.php
}}

{{TodoItem
|When full page writes are off, write CRC to WAL and check file system blocks on recovery
|If CRC check fails during recovery, remember the page in case a later CRC for that page properly matches. The difficulty is that hint bits are not WAL logged, meaning a valid page might not match the earlier CRC.}}

{{TodoItem
|Write full pages during file system write and not when the page is modified in the buffer cache
|This allows most full page writes to happen in the background writer. It might cause problems for applying WAL on recovery into a partially-written page, but later the full page will be replaced from WAL.
* [http://archives.postgresql.org/message-id/CAGvK12UST-tPhyLrSLuSpwFxZbAO79yYrhV2xaLmS2MkUxNUVQ@mail.gmail.com Page Checksums + Double Writes]
}}

{{TodoItem
|Reduce WAL traffic so only modified values are written rather than entire rows
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01589.php <nowiki>Reduction in WAL for UPDATEs</nowiki>]
}}

{{TodoItem
|Allow WAL information to recover corrupted pg_controldata
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00025.php <nowiki>Re: [HACKERS] pg_resetxlog -r flag</nowiki>]
}}

{{TodoItem
|Find a way to reduce rotational delay when repeatedly writing last WAL page
|Currently fsync of WAL requires the disk platter to perform a full rotation to fsync again. One idea is to write the WAL to different offsets that might reduce the rotational delay.
* [http://archives.postgresql.org/pgsql-hackers/2002-11/msg00483.php <nowiki>500 tpsQL + WAL log implementation</nowiki>]
}}

{{TodoItem
|Speed WAL recovery by allowing more than one page to be prefetched
|This should be done utilizing the same infrastructure used for prefetching in general to avoid introducing complex error-prone code in WAL replay.
* [http://archives.postgresql.org/pgsql-general/2007-12/msg00683.php <nowiki>Slow PITR restore</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00497.php <nowiki>Re: [GENERAL] Slow PITR restore</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg01279.php <nowiki>Read-ahead and parallelism in redo recovery</nowiki>]
}}

{{TodoItem
|Improve WAL concurrency by increasing lock granularity
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00556.php <nowiki>Reworking WAL locking</nowiki>]
}}

{{TodoItem
|Be more aggressive about creating WAL files
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01325.php <nowiki>Re: PANIC caused by open_sync on Linux</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2004-07/msg01075.php <nowiki>PreallocXlogFiles</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2005-04/msg00556.php <nowiki>WAL/PITR additional items</nowiki>]
}}

{{TodoItem
|Have resource managers report the duration of their status changes
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01468.php <nowiki>Recovery of Multi-stage WAL actions</nowiki>]
}}

{{TodoItem
|Move pgfoundry's xlogdump to /contrib and have it rely more closely on the WAL backend code
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00035.php <nowiki>xlogdump</nowiki>]
}}

{{TodoItem
|Close deleted WAL files held open in *nix by long-lived read-only backends
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg01754.php <nowiki>Deleted WAL files held open by backends in Linux</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00060.php <nowiki>Re: Deleted WAL files held open by backends in Linux</nowiki>]
}}

== Optimizer / Executor ==

{{TodoItem
|Improve selectivity functions for geometric operators}}

{{TodoItem
|Consider increasing the default values of from_collapse_limit, join_collapse_limit, and/or geqo_threshold
* [http://archives.postgresql.org/message-id/4136ffa0905210551u22eeb31bn5655dbe7c9a3aed5@mail.gmail.com from_collapse_limit vs. geqo_threshold]
}}

{{TodoItem
|Improve ability to display optimizer analysis using OPTIMIZER_DEBUG
* http://archives.postgresql.org/pgsql-hackers/2012-08/msg00597.php
}}

{{TodoItem
|Log statements where the optimizer row estimates were dramatically different from the number of rows actually found?}}

{{TodoItem
|Consider compressed annealing to search for query plans
|This might replace GEQO.
* http://archives.postgresql.org/message-id/15658.1241278636%40sss.pgh.pa.us
}}

{{TodoItem
|Improve use of expression indexes for ORDER BY
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01553.php <nowiki>Resjunk sort columns, Heikki's index-only quals patch, and bug #5000</nowiki>]
}}

{{TodoItem
|Modify the planner to better estimate caching effects
* http://archives.postgresql.org/pgsql-performance/2010-11/msg00117.php
}}

{{TodoItem
|Allow shared buffer cache contents to affect index cost computations
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg01140.php
}}

{{TodoItem
|Allow the CTE (Common Table Expression) optimization fence to be optionally disabled
* http://archives.postgresql.org/pgsql-hackers/2012-09/msg00700.php
* http://archives.postgresql.org/pgsql-performance/2012-11/msg00161.php
}}

=== Hashing ===
{{TodoSubsection}}

{{TodoItem
|Consider using a hash for joining to a large IN (VALUES ...) list
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00450.php <nowiki>Planning large IN lists</nowiki>]
}}

{{TodoItem
|Allow single batch hash joins to preserve outer pathkeys
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00806.php Re: Potential Join Performance Issue]
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoItem
|"lazy" hash tables - look up only the tuples that are actually requested
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoItem
|Avoid building the same hash table more than once during the same query
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoItem
|Avoid hashing for distinct and then re-hashing for hash join
* [http://archives.postgresql.org/message-id/4136ffa0902191346g62081081v8607f0b92c206f0a@mail.gmail.com Re: Fixing Grittner's planner issues]
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoEndSubsection}}

== Background Writer ==

{{TodoItem
|Consider having the background writer update the transaction status hint bits before writing out the page
|Implementing this requires the background writer to have access to system catalogs and the transaction status log.}}

{{TodoItem
|Consider adding buffers the background writer finds reusable to the free list
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php <nowiki>Background LRU Writer/free list</nowiki>]
* [http://archives.postgresql.org/message-id/CA+U5nMKtvyDcV4zTr7bq7t6cA2nBfLxCJ8tQgVBnc5ddRPO+Bg@mail.gmail.com our buffer replacement strategy is kind of lame]
}}

{{TodoItem
|Automatically tune bgwriter_delay based on activity rather then using a fixed interval
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php <nowiki>Background LRU Writer/free list</nowiki>]
* [http://archives.postgresql.org/message-id/CA+U5nMKtvyDcV4zTr7bq7t6cA2nBfLxCJ8tQgVBnc5ddRPO+Bg@mail.gmail.com our buffer replacement strategy is kind of lame]
}}

{{TodoItem
|Consider whether increasing BM_MAX_USAGE_COUNT improves performance
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg01007.php <nowiki>Bgwriter LRU cleaning: we've been going at this all wrong</nowiki>]
}}

{{TodoItem
|Test to see if calling PreallocXlogFiles() from the background writer will help with WAL segment creation latency
* [http://archives.postgresql.org/pgsql-patches/2007-06/msg00340.php <nowiki>Re: Load Distributed Checkpoints, final patch</nowiki>]
}}

== Concurrent Use of Resources ==

{{TodoItem
|Do async I/O for faster random read-ahead of data
|Async I/O allows multiple I/O requests to be sent to the disk with results coming back asynchronously.
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg00820.php <nowiki>Asynchronous I/O Support</nowiki>]
* [http://archives.postgresql.org/pgsql-performance/2007-09/msg00255.php <nowiki>Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00027.php <nowiki>There's random access and then there's random access</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-01/msg00170.php <nowiki>Bitmap index scan preread using posix_fadvise (Was: There's random access and then there's random access)</nowiki>]
The above patch is already applied as of 8.4, but it still remains to figure out how to handle plain indexscans effectively.
* [http://archives.postgresql.org//pgsql-hackers/2009-01/msg00806.php Problems with the patch submitted for posix_fadvise in index scans]
}}

{{TodoItem
|Experiment with multi-threaded backend for better I/O utilization
|This would allow a single query to make use of multiple I/O channels simultaneously. One idea is to create a background reader that can pre-fetch sequential and index scan pages needed by other backends. This could be expanded to allow concurrent reads from multiple devices in a partitioned table.
* http://archives.postgresql.org/pgsql-performance/2011-02/msg00123.php
* http://archives.postgresql.org/pgsql-hackers/2012-10/msg01139.php
}}

{{TodoItem
|Experiment with multi-threaded backend for better CPU utilization
|This would allow several CPUs to be used for a single query, such as for sorting or query execution.
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00945.php <nowiki>Multi CPU Queries - Feedback and/or suggestions wanted!</nowiki>]
}}

{{TodoItem
|SMP scalability improvements
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00439.php <nowiki>Straightforward changes for increased SMP scalability</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00206.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00361.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]
}}

== TOAST ==

{{TodoItem
|Allow user configuration of TOAST thresholds
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00213.php <nowiki>Re: Proposed adjustments in MaxTupleSize and toastthresholds</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00082.php <nowiki>pg_lzcompress strategy parameters</nowiki>]
}}

{{TodoItem
|Reduce unnecessary cases of deTOASTing
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00895.php <nowiki>Re: [PATCHES] Eliminate more detoast copies for packed varlenas</nowiki>]
}}

{{TodoItem
|Reduce costs of repeat de-TOASTing of values
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg01096.php <nowiki>WIP patch: reducing overhead for repeat de-TOASTing</nowiki>]
}}

== Monitoring ==
{{TodoItem
|Expand pg_stat_activity for easier integration with monitoring tools
|* http://archives.postgresql.org/message-id/4DFA13A5.2060200@2ndQuadrant.com
}}

{{TodoItem
|Add column to pg_stat_activity that shows the progress of long-running commands like CREATE INDEX and VACUUM
* [http://archives.postgresql.org/pgsql-patches/2008-04/msg00203.php <nowiki>EXPLAIN progress info</nowiki>]
* The CLUSTER/VACUUM FULL implementation would also be useful to track this way
}}

{{TodoItem
|Have pg_stat_activity display query strings in the correct client encoding
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00131.php <nowiki>pg_stats queries versus per-database encodings</nowiki>]
}}

{{TodoItemEasy
|Expose pg_controldata via an SQL interface
|Helpful for monitoring replicated databases
* http://archives.postgresql.org/message-id/4B901D73.8030003@agliodbs.com
* [http://archives.postgresql.org/message-id/4B959D7A.6010907@joeconway.com initial patch]
}}

{{TodoItem
| Add entry creation timestamp column to pg_stat_replication
* http://archives.postgresql.org/pgsql-hackers/2011-08/msg00694.php
}}

{{TodoItem
| Allow reporting of stalls due to wal_buffer wrap-around
* http://archives.postgresql.org/pgsql-hackers/2012-02/msg00826.php
}}

{{TodoItem
| Restructure pg_stat_database columns tup_returned and tup_fetched to return meaningful values
* http://www.postgresql.org/message-id/20121012060345.GA29214@toroid.org
}}

== Miscellaneous Performance ==

{{TodoItem
|Use mmap() rather than SYSV for shared buffers?
|This would remove the requirement for SYSV SHM but would introduce portability issues. Anonymous mmap (or mmap to /dev/zero) is required to prevent I/O overhead. We could also consider mmap() for writing WAL.
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00750.php
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00756.php
}}

{{TodoItem
|Rather than consider mmap()-ing in 8k pages, consider mmap()'ing entire files into a backend?
|Doing I/O to large tables would consume a lot of address space or require frequent mapping/unmapping. Extending the file also causes mapping problems that might require mapping only individual pages, leading to thousands of mappings. Another problem is that there is no way to _prevent_ I/O to disk from the dirty shared buffers so changes could hit disk before WAL is written.
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01239.php
}}

{{TodoItem
|Consider ways of storing rows more compactly on disk:
* Reduce the row header size?
* Consider reducing on-disk varlena length from four bytes to two because a heap row cannot be more than 64k in length}}

{{TodoItem
|Consider transaction start/end performance improvements
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00948.php <nowiki>Reducing Transaction Start/End Contention</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00361.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]
}}

{{TodoItem
|Allow configuration of backend priorities via the operating system
|Though backend priorities make priority inversion during lock waits possible, research shows that this is not a huge problem.
* [http://archives.postgresql.org/pgsql-general/2007-02/msg00493.php <nowiki>Priorities for users or queries?</nowiki>]
}}

{{TodoItem
|Consider increasing the minimum allowed number of shared buffers
* [http://archives.postgresql.org/pgsql-bugs/2008-02/msg00157.php <nowiki>Re: [PATCH] Don't bail with legitimate -N/-B options</nowiki>]
}}

{{TodoItem
|Consider if CommandCounterIncrement() can avoid its AcceptInvalidationMessages() call
* [http://archives.postgresql.org/pgsql-committers/2007-11/msg00585.php <nowiki>pgsql: Avoid incrementing the CommandCounter when</nowiki>]
}}

{{TodoItem
|Consider Cartesian joins when both relations are needed to form an indexscan qualification for a third relation
* [http://archives.postgresql.org/pgsql-performance/2007-12/msg00090.php <nowiki>Re: TB-sized databases</nowiki>]
}}

{{TodoItem
|Consider not storing a NULL bitmap on disk if all the NULLs are trailing
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00624.php <nowiki>Proposal for Null Bitmap Optimization(for Trailing NULLs)</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-12/msg00109.php <nowiki>Re: [HACKERS] Proposal for Null Bitmap Optimization(for TrailingNULLs)</nowiki>]
}}

{{TodoItem
|Sort large UPDATE/DELETEs so it is done in heap order
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg01119.php <nowiki>Possible future performance improvement: sort updates/deletes by ctid</nowiki>]
}}

{{TodoItem
|Consider decreasing the I/O caused by updating tuple hint bits
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00847.php <nowiki>Hint Bits and Write I/O</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00199.php <nowiki>Re: [HACKERS] Hint Bits and Write I/O</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00695.php
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00792.php
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg01063.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01408.php
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01453.php
}}

{{TodoItem
|Avoid the requirement of freezing pages that are infrequently modified
|If all rows on a page are visible, it is possible to set a bit in the visibility map (once the visibility map is 100% reliable) and not need to freeze the page, avoiding a page rewrite
* http://archives.postgresql.org/message-id/4BF701CF.2090205@agliodbs.com
* http://archives.postgresql.org/pgsql-hackers/2010-06/msg00082.php
}}

{{TodoItem
|Avoid reading in b-tree pages when replaying vacuum records in hot standby mode
* [http://archives.postgresql.org/message-id/1272571938.4161.14739.camel@ebony <nowiki>Hot Standby tuning for btree_xlog_vacuum()</nowiki>]
}}

{{TodoItem
|Restructure truncation logic to be more resistant to failure
|This also involves not writing dirty buffers for a truncated or dropped relation
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01032.php
}}

{{TodoItem
|Consider adding logic to increase large tables by more than 8k
|This would reduce file system fragmentation
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00337.php
}}

== Miscellaneous Other ==

{{TodoItem
|Deal with encoding issues for filenames in the server filesystem
* {{MessageLink|20090413184335.39BE.52131E4D@oss.ntt.co.jp|a proposed patch here}}
* {{MessageLink|8484.1244655656@sss.pgh.pa.us|some issues about it here}}
* {{MessageLink|20100107103740.97A5.52131E4D@oss.ntt.co.jp|Windows-specific patch here}}
}}

{{TodoItem
|Deal with encoding issues in the output of localeconv()
* [http://archives.postgresql.org/message-id/40c6d9160904210658y590377cfw6dbbecb53d2b8be0@mail.gmail.com bug report]
* [http://archives.postgresql.org/message-id/49EF8DA0.90008@tpf.co.jp draft patch]
* [http://archives.postgresql.org/message-id/21710.1243620986@sss.pgh.pa.us review of patch]
}}

{{TodoItem
|Provide schema name and other fields available from SQL GET DIAGNOSTICS in error reports
* [http://archives.postgresql.org/message-id/dcc563d10810211907n3c59a920ia9eb7cd2a6d5ea58@mail.gmail.com <nowiki>How to get schema name which violates fk constraint</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg00846.php <nowiki>patch - Report the schema along table name in a referential failure error message</nowiki>]
* {{MessageLink|3191.1263306359@sss.pgh.pa.us|Re: NOT NULL violation and error-message}}
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg00213.php <nowiki>the case for machine-readable error fields</nowiki>]
}}

{{TodoItemDone
| Provide [http://developer.postgresql.org/pgdocs/postgres/libpq-connect.html#LIBPQ-CONNECT-FALLBACK-APPLICATION-NAME fallback_application_name] in contrib/pgbench, oid2name, and dblink.
* {{MessageLink|w2g9837222c1004070216u3bc46b3ahbddfdffdbfb46212@mail.gmail.com|fallback_application_name and pgbench}}
}}

{{TodoItem
|Add 64-bit support to /contrib/pgbench
* http://archives.postgresql.org/pgsql-hackers/2010-07/msg00153.php
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00705.php
}}

== Source Code ==

{{TodoItemEasy
|Remove warnings created by -Wcast-align}}

{{TodoItem
|Move platform-specific ps status display info from ps_status.c to ports}}

{{TodoItem
|Add optional CRC checksum to heap and index pages
|One difficulty is how to prevent hint bit changes from affecting the computed CRC checksum.
* http://archives.postgresql.org/message-id/19934.1226601952%40sss.pgh.pa.us
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00002.php <nowiki>Re: Block-level CRC checks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01028.php <nowiki>double-buffering page writes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00524.php <nowiki>Re: Block-level CRC checks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg01101.php <nowiki>Re: Block-level CRC checks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00011.php <nowiki>Re: Block-level CRC checks</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00249.php
* http://archives.postgresql.org/message-id/20111221215913.GA4536@fetter.org
* http://archives.postgresql.org/message-id/CA+U5nMJzQyxcObkpNAf1SYTX-gO_Mom3O9JXHnGpxRo1kXJ7ww@mail.gmail.com
* http://archives.postgresql.org/pgsql-hackers/2012-01/msg00128.php
* http://archives.postgresql.org/pgsql-hackers/2012-01/msg00113.php
* http://archives.postgresql.org/pgsql-hackers/2012-02/msg00172.php
* http://archives.postgresql.org/pgsql-hackers/2012-03/msg00001.php
* http://archives.postgresql.org/pgsql-hackers/2012-03/msg00188.php
}}

{{TodoItem
|Consider a faster CRC32 algorithm
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01112.php
}}

{{TodoItem
|Allow cross-compiling by generating the zic database on the target system}}

{{TodoItem
|Improve NLS maintenance of libpgport messages linked onto applications}}

{{TodoItem
|Use UTF8 encoding for NLS messages so all server encodings can read them properly}}

{{TodoItem
|Allow creation of universal binaries for Darwin
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00884.php <nowiki>Getting to universal binaries for Darwin</nowiki>]
}}

{{TodoItem
|Consider GnuTLS if OpenSSL license becomes a problem
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00892.php
* [http://archives.postgresql.org/pgsql-patches/2006-05/msg00040.php <nowiki>[PATCH] Add support for GnuTLS</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg01213.php <nowiki>TODO: GNU TLS</nowiki>]
}}

{{TodoItem
|Consider making NAMEDATALEN more configurable in future releases}}

{{TodoItem
|Research use of signals and sleep wake ups
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00003.php <nowiki>Restartable signals 'n all that</nowiki>]
}}

{{TodoItem
|Allow C++ code to more easily access backend code
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00302.php <nowiki>Mostly Harmless: Welcoming our C++ friends</nowiki>]
}}

{{TodoItem
|Consider simplifying how memory context resets handle child contexts
* [http://archives.postgresql.org/pgsql-patches/2007-08/msg00067.php <nowiki>Re: Memory leak in nodeAgg</nowiki>]
}}

{{TodoItem
|Create three versions of libpgport to simplify client code
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00154.php <nowiki>8.4 TODO item: make src/port support libpq and ecpg directly</nowiki>]
}}

{{TodoItem
|Improve detection of shared memory segments being used by others by checking the SysV shared memory field 'nattch'
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00656.php <nowiki>postgresql in FreeBSD jails: proposal</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00673.php <nowiki>Re: postgresql in FreeBSD jails: proposal</nowiki>]
}}

{{TodoItem
|Implement the non-threaded Avahi service discovery protocol
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00939.php <nowiki>Re: [PATCHES] Avahi support for Postgresql</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-02/msg00097.php <nowiki>Re: Avahi support for Postgresql</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg01211.php <nowiki>Re: [PATCHES] Avahi support for Postgresql</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-04/msg00001.php <nowiki>Re: [HACKERS] Avahi support for Postgresql</nowiki>]
}}

{{TodoItem
|Reduce data row alignment requirements on some 64-bit systems
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00369.php <nowiki>[WIP] Reduce alignment requirements on 64-bit systems.</nowiki>]
}}

{{TodoItem
|Restructure TOAST internal storage format for greater flexibility
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00049.php <nowiki>Re: PG_PAGE_LAYOUT_VERSION 5 - time for change</nowiki>]
}}

{{TodoItem
| Add regression tests for pg_dump/restore
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01967.php <nowiki>"make install-check-pg_dump" target in src/regress]</nowiki>]
}}

{{TodoItem
| Research different memory allocation methods for lists
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01467.php
}}

{{TodoItem
| Consider removing the attribute options cache
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00039.php
}}

{{TodoItem
| Restructure /contrib section
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00705.php
}}

{{TodoItem
| Consider adding explicit huge page support
* http://archives.postgresql.org/pgsql-hackers/2012-07/msg00123.php
}}

=== /contrib/pg_upgrade ===
{{TodoSubsection}}

{{TodoItem
|Handle large object comments
|This is difficult to do because the large object doesn't exist when --schema-only is loaded.
}}

{{TodoItem
|Consider using pg_depend for checking object usage in version.c
}}

{{TodoItem
|If reindex is necessary, allow it to be done in parallel with pg_dump custom format
}}

{{TodoItem
|Migrate pg_statistic by dumping it out as a flat file, so analyze is not necessary
|pg_class.oid is not preserved so schema.tablename must be used.
* [http://archives.postgresql.org/message-id/CAAZKuFaWdLkK8eozSAooZBets9y_mfo2HS6urPAKXEPbd-JLCA@mail.gmail.com pg_upgrade and statistics]
}}

{{TodoItem
|Improve testing, perhaps using the buildfarm
|The buildfarm has access to multiple versions of PostgreSQL.
}}

{{TodoItem
|Create machine-readable output of pg_controldata
|This would avoid parsing its output. The problem is we need pg_controldata output from both the old and new clusters so we would need to support both formats.
}}

{{TodoItem
|Find cleaner way to start/stop dedicated servers for upgrades
* http://archives.postgresql.org/pgsql-hackers/2012-08/msg00275.php
}}

{{TodoItem
|Consider a way to run pg_upgrade on standby servers
* http://archives.postgresql.org/pgsql-hackers/2012-07/msg00453.php
* http://archives.postgresql.org/pgsql-hackers/2012-09/msg00056.php
}}

{{TodoEndSubsection}}

=== Windows ===
{{TodoSubsection}}

{{TodoItem
|Remove configure.in check for link failure when cause is found}}

{{TodoItem
|Remove readdir() errno patch when runtime/mingwex/dirent.c rev 1.4 is released}}

{{TodoItem
|Allow psql to use readline once non-US code pages work with backslashes}}

{{TodoItem
|Fix problem with shared memory on the Win32 Terminal Server}}

{{TodoItem
|Improve signal handling
* [http://archives.postgresql.org/pgsql-patches/2005-06/msg00027.php <nowiki>Simplify Win32 Signaling code</nowiki>]
}}

{{TodoItem
|Convert MSVC build system to remove most batch files
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00961.php <nowiki>MSVC build system</nowiki>]
}}

{{TodoItem
|Support pgxs when using MSVC}}

{{TodoItem
|Fix MSVC NLS support, like for to_char()
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00485.php <nowiki>NLS on MSVC strikes back!</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php <nowiki>Fix for 8.3 MSVC locale (Was [HACKERS] NLS on MSVC strikes back!)</nowiki>]
}}

{{TodoItem
|Find a correct rint() substitute on Windows
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00808.php <nowiki>Minor bug in src/port/rint.c</nowiki>]
}}

{{TodoItem
|Fix global namespace issues when using multiple terminal server sessions
* [http://archives.postgresql.org/message-id/48F3BFCC.8030107@dunslane.net problems with Windows global namespace]}}

{{TodoItem
|Change from the current autoconf/gmake build system to cmake
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg01869.php <nowiki>About CMake (was Re: [COMMITTERS] pgsql: Append major version number and for libraries soname major)</nowiki>]
}}

{{TodoItem
|Improve consistency of path separator usage
* http://archives.postgresql.org/message-id/49C0BDC5.4010002@hagander.net
}}

{{TodoItem
|Fix cross-compiling on Windows
* http://archives.postgresql.org/pgsql-bugs/2010-10/msg00110.php
}}

{{TodoItem
|Reduce file statistics overhead on directory reads
* http://www.postgresql.org/message-id/1338325561.82125.YahooMailNeo@web39304.mail.mud.yahoo.com
}}

{{TodoEndSubsection}}

=== Wire Protocol Changes ===
{{TodoSubsection}}

{{TodoItem
|Allow dynamic character set handling}}

{{TodoItem
|Add decoded type, length, precision}}

{{TodoItem
|Mark result columns as known-not-null when possible
* [http://archives.postgresql.org/pgsql-hackers/2010-11/msg01029.php <nowiki>Adding nullable indicator to Describe</nowiki>]
}}

{{TodoItem
|Provide more control over planner treatment of statements being prepared}}

{{TodoItem
|Use compression
|If SSL is used, hopefully avoid the overhead of key negotiation and encryption
* http://archives.postgresql.org/pgsql-hackers/2012-06/msg00793.php
}}

{{TodoItem
|Update clients to use data types, typmod, schema.table.column names of result sets using new statement protocol}}

{{TodoItem
|Set protocol for wire format negotiation
* [http://archives.postgresql.org/message-id/CACMqXCKkGrGXxQhjHCKCe0B8hn6sTt-1sdgHZOSGQMxrusOsQA@mail.gmail.com GUC_REPORT for protocol tunables]
}}

{{TodoItem
|Make sure upgrading to a 4.1 protocol version will actually work smoothly
* [http://archives.postgresql.org/message-id/28307.1318255008@sss.pgh.pa.us Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable]
}}

{{TodoEndSubsection}}

== Documentation ==

{{TodoItemEasy
| Add contrib functions to the index
* Add the functions and GUCs in the contrib modules to [http://www.postgresql.org/docs/current/static/sql-createindex.html the documentation index]: [http://archives.postgresql.org/message-id/50A2E173.6030404@2ndQuadrant.com per list discussion]
}}

{{TodoItem
|Convert single quotes to apostrophes in the PDF documentation
* [http://archives.postgresql.org/pgsql-docs/2007-12/msg00059.php <nowiki>SGML docs and pdf single-quotes</nowiki>]
}}

{{TodoItem
|Provide a manpage for postgresql.conf
* {{messageLink|20080819194311.GH4428@alvh.no-ip.org|A smaller default postgresql.conf}}
* {{messageLink|200808211910.37524.peter_e@gmx.net|A smaller default postgresql.conf}}
}}

{{TodoItem
|Change the manpage-generating toolchain to use the new XML-based docbook2x tools
* {{messageLink|200808211910.37524.peter_e@gmx.net|A smaller default postgresql.conf}}
}}

{{TodoItem
|Consider changing documentation format from SGML to XML
* [http://archives.postgresql.org/pgsql-docs/2006-12/msg00152.php <nowiki>Re: Authoring Tools WAS: Switching to XML</nowiki>]
* http://archives.postgresql.org/pgsql-docs/2011-04/msg00020.php
* http://wiki.postgresql.org/wiki/Switching_PostgreSQL_documentation_from_SGML_to_XML
}}

{{TodoItem
|Document support for N<nowiki>' '</nowiki> national character string literals, if it matches the SQL standard
* http://archives.postgresql.org/message-id/1275895438.1849.1.camel@fsopti579.F-Secure.com
}}

{{TodoItem
|Add diagrams to the documentation
* http://archives.postgresql.org/pgsql-docs/2010-07/msg00001.php
}}

== Exotic Features ==

{{TodoItem
|Add pre-parsing phase that converts non-ISO syntax to supported syntax
|This could allow SQL written for other databases to run without modification.}}

{{TodoItem
|Allow plug-in modules to emulate features from other databases}}

{{TodoItem
|Add features of Oracle-style packages
|A package would be a schema with session-local variables, public/private functions, and initialization functions. It is also possible to implement these capabilities in any schema and not use a separate "packages" syntax at all.
* [http://archives.postgresql.org/pgsql-hackers/2006-08/msg00384.php <nowiki>proposal for PL packages for 8.3.</nowiki>]
}}

{{TodoItem
|Consider allowing control of upper/lower case folding of unquoted identifiers
* [http://archives.postgresql.org/pgsql-hackers/2004-04/msg00818.php <nowiki>Bringing PostgreSQL torwards the standard regarding case folding</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg01527.php <nowiki>Re: [SQL] Case Preservation disregarding case sensitivity?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00849.php <nowiki>TODO Item: Consider allowing control of upper/lower case folding of unquoted, identifiers</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00415.php <nowiki>Identifier case folding notes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00415.php <nowiki>Identifier case folding notes</nowiki>]
}}

{{TodoItem
|Add autonomous transactions
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00893.php <nowiki>autonomous transactions</nowiki>]
}}

{{TodoItem
|Give query progress indication
* [[Query progress indication]]
}}

{{TodoItem
|Rethink our type system
* [[Rethinking datatypes]]
}}

== Features We Do ''Not'' Want ==

The following features have been discussed ad nauseum on the PostgreSQL mailing lists and the consensus has been that the project is not interested in them. As such, if you are going to bring them up as potential features, you will want to be familiar with all of the arguments against these features which have been previously made over the years. If you decide to work on such features anyway, you should be aware that you face a higher-than-normal barrier to get the Project to accept them.

{{TodoItem
|All backends running as threads in a single process (not wanted)
|This eliminates the process protection we get from the current setup. Thread creation is usually the same overhead as process creation on modern systems, so it seems unwise to use a pure threaded model, and MySQL and DB2 have demonstrated that threads introduce as many issues as they solve. Threading specific operations such as I/O, seq scans, and connection management has been discussed and will probably be implemented to enable specific performance features. Moving to a threaded engine would also require halting all other work on PostgreSQL for one to two years.}}

{{TodoItem
|"Oracle-style" optimizer hints (not wanted)
|Optimizer hints, as implemented in Oracle and other RDBMSes, are used to work around problems in the optimizer and introduce upgrade and maintenance issues. We would rather have such problems reported and fixed. We have discussed a more sophisticated system of per-class cost adjustment instead, but a specification remains to be developed. See [[OptimizerHintsDiscussion|Optimizer Hints Discussion]] for further information.}}

{{TodoItem
|Embedded server (not wanted)
|While PostgreSQL clients runs fine in limited-resource environments, the server requires multiple processes and a stable pool of resources to run reliably and efficiently. Stripping down the PostgreSQL server to run in the same process address space as the client application would add too much complexity and failure cases. Besides, there are several very mature embedded SQL databases already available.}}

{{TodoItem
|Obfuscated function source code (not wanted)
|Obfuscating function source code has minimal protective benefits because anyone with super-user access can find a way to view the code. At the same time, it would greatly complicate backups and other administrative tasks. To prevent non-super-users from viewing function source code, remove SELECT permission on pg_proc.
* [http://archives.postgresql.org/pgsql-general/2008-09/msg00668.php <nowiki>Obfuscated stored procedures (was Re: Oracle and Postgresql)</nowiki>]
}}

{{TodoItem
|Indeterminate behavior for the GROUP BY clause (not wanted)
|At least one other database product allows specification of a subset of the result columns which GROUP BY would need to be able to provide predictable results; the server is free to return any value from the group. This is not viewed as a desirable feature. PostgreSQL 9.1 allows result columns that are not referenced by GROUP BY if a primary key for the same table is referenced in GROUP BY.
* [http://archives.postgresql.org/pgsql-hackers/2010-03/msg00297.php <nowiki>Re: SQL compatibility reminder: MySQL vs PostgreSQL</nowiki>]
}}

</div>

[[Category:Todo]]

PGDay FOSDEM 2013

2013-01-07T19:21:47Z

Mastermind: /* Dinner */

= PGDay FOSDEM 2013 =

This is the first PgDay we hold in Belgium. FOSDEM PGDay 2013 will be held on Feb 1st in Brussels, Belgium, at the Radisson Blu Royal hotel. As an extension to the regular PostgreSQL devroom at FOSDEM, it will cover topics for PostgreSQL users, developers and contributors, and anybody else interested in PostgreSQL

== Details ==

* '''Date:''' Feb 01st, 2013 9am-5pm
* '''Venue:''': Radisson Blu Royal Hotel
* '''Coordinator:''': PostgreSQL Europe [mailto:contact@pgconf.eu contact@pgconf.eu]
* '''Website:''': http://fosdem2013.pgconf.eu/

== Registration ==

Free attendance, web registration required: http://fosdem2013.pgconf.eu/registration/ (limited seats)

== Schedule ==

Schedule is be published at: http://fosdem2013.pgconf.eu/schedule/

== Location and Venue ==

http://fosdem2013.pgconf.eu/venue/

Address:

http://www.radissonblu.com/royalhotel-brussels/location

== Dinner ==

We are organizing a dinner after the event on Friday 1st, 2013 at Hard Rock Cafe Brussels. We have limited (30) number of seats, so please add your name to this list before going there.

If you are bringing someone to the event, make sure you enter your name *twice* (or more) on the list, so the attendee count matches!

Attendees:

# Devrim Gündüz
# Devrim Gündüz +1
# Magnus Hagander
# Andreas Scherbaum
# Andreas Scherbaum +1
# Jean-Paul Argudo
# Patryk Kordylewski
# Patryk Kordylewski +1
# Dimitri Fontaine
# Julien Rouhaud
# Dave Page
# Marc Cousin
# Stéphane Schildknecht
# Stéphane Schildknecht +1
# Jehan-Guillaume de Rorthais
# Guillaume Lelarge
# Markus Winand
# Marc Balmer
# Marc Balmer +1
# Stefan Kaltenbrunner

[[Category:PostgreSQL Events]]

Infrastructure team

2013-01-02T18:01:05Z

Mastermind: add sfrost

== Infrastructure Team ==

The Infrastructure team is responsible for running all of the postgresql.org infrastructure. This includes a wide variety of public and non-public services. PostgreSQL website development is discussed on the [http://archives.postgresql.org/pgsql-www/ pgsql-www mailing list]. Source code for the postgresql.org web site is stored in a public GIT repository, and is available on [http://git.postgresql.org/gitweb/?p=pgweb.git;a=summary]

== Infrastructure Team Members ==

The following people are part of the sysadmin team running the postgresql.org infrastructure. Note that not all of those people do have root-level access on all servers.

* Joshua Drake
* Marc Fournier
* Stephen Frost
* Magnus Hagander
* Álvaro Herrera
* Stefan Kaltenbrunner
* Greg Sabino Mullane
* Dave Page
* Robert Treat

[[Category:Community]]

Infrastructure team

2012-08-18T19:39:07Z

Mastermind: we have been on GIT for ages now

== Infrastructure Team ==

The Infrastructure team is responsible for running all of the postgresql.org infrastructure. This includes a wide variety of public and non-public services. PostgreSQL website development is discussed on the [http://archives.postgresql.org/pgsql-www/ pgsql-www mailing list]. Source code for the postgresql.org web site is stored in a public GIT repository, and is available on [http://git.postgresql.org/gitweb/?p=pgweb.git;a=summary]

== Infrastructure Team Members ==

The following people are part of the sysadmin team running the postgresql.org infrastructure. Note that not all of those people do have root-level access on all servers.

* Joshua Drake
* Marc Fournier
* Magnus Hagander
* Álvaro Herrera
* Stefan Kaltenbrunner
* Greg Sabino Mullane
* Dave Page
* Robert Treat

[[Category:Community]]

FAQ/de

2011-12-06T18:43:11Z

Mastermind: correct url

{{Languages}}

== Allgemeine Fragen ==

=== Was ist PostgreSQL? Wie wird es ausgesprochen? ===

Die (englische) Aussprache ist "Post-Gres-Q-L". Im allgemeinen
Sprachgebrauch hat sich die Kurzform "Postgres" auch durchgesetzt.
(Für diejenigen, die es interessiert: eine MP3-Datei mit der
amerikanischen Aussprache befindet sich hier:
http://www.postgresql.org/files/postgresql.mp3

PostgreSQL ist ein objektrelationales Datenbanksystem, das die Vorzüge
von kommerziellen Datenbanksystemen mit zukunftsweisenden Innovationen
kombiniert. PostgreSQL ist freie Software und dessen kompletter
Quellcode ist öffentlich verfügbar.

Die PostgreSQL-Entwicklung wird von einem Team von meist freiwilligen
Entwicklern durchgeführt. Dieses Team ist für die Gesamtentwicklung
von PostgreSQL verantwortlich. Es handelt sich um ein
Gemeinschaftsprojekt, das nicht von einer bestimmten Firma
kontrolliert wird. Lesen Sie die Entwickler-FAQ:
http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn Sie an einer
Mitarbeit interessiert sind.

=== Wer kontrolliert PostgreSQL? ===

Falls Sie nach dem Namen eines etwaigen Inhabers bzw. nach einem
allmächtigen Zentralkommittee suchen - sparen Sie sich die Mühe, sowas
existiert gar nicht. Es gibt zwar das "Core Committee" sowie
Entwickler, die CVS-Schreibberechtigung haben, jedoch haben diese
Gruppen eher nur eine administrative Rolle. Das Projekt wird durch die
Community gesteuert, die aus den Entwicklern sowie natürlich auch den
Nutzern besteht - jeder kann daran teilnehmen. (Lesen Sie die
Entwickler-FAQ: http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn
Sie an der PostgreSQL-Entwicklung teilnehmen möchten).

=== Welchem Copyright unterliegt PostgreSQL? ===

PostgreSQL wird unter der klassischen BSD-Lizenz herausgegeben. Im
Grunde genommen erlaubt diese den Nutzern, beliebig mit dem Code
umzugehen, auch der Weiterverkauf von Binärversionen ohne Quellcode
ist erlaubt. Die einzige Einschränkung besteht darin, dass PostgreSQL
auf keinen Fall für etwaige Probleme mit der Software haftet. Außerdem
muß der Copyright- Text in allen Kopien der Software enthalten sein.
Dies ist der Originaltext der BSD-Lizenz:

PostgreSQL Data Base Management System

Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group
Portions Copyright (c) 1994-6 Regents of the University of California

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose, without fee, and without a written
agreement is hereby granted, provided that the above copyright notice
and this paragraph and the following two paragraphs appear in all
copies.

IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY
FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES,
INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND
ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE
PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF
CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT,
UPDATES, ENHANCEMENTS, OR MODIFICATIONS.

Es gilt die Copyright-Klausel im Original!

=== Auf welchen Plattformen läuft PostgreSQL? ===

Normalerweise kann PostgreSQL auf jeder modernen UNIX-kompatiblen
Plattform eingesetzt werden. Diejenigen Plattformen, die bei der
jeweiligen Versionsfreigabe getestet wurden, sind in den
Installationsanleitungen aufgelistet.

PostgreSQL läuft auch auf Microsoft NT-basierten Betriebssystemen wie
Windows 2000 SP4, XP und Server 2003. Ein vorgefertigtes
Installationspaket kann von http://pgfoundry.org/projects/pginstaller
heruntergeladen werden. DOS-basierte Windows-Versionen (Win95, Win98,
WinMe) können PostgreSQL nur mit Hilfe der Cygwin-Umgebung ausführen.

=== Woher bekomme ich PostgreSQL? ===

Per Web-Browser hier: http://www.postgresql.org/ftp/ und per FTP hier:
ftp://ftp.postgresql.org/pub/.

=== Was ist die neueste Version von PostgreSQL? ===

Die neueste Version von PostgreSQL kann auf der [http://www.postgresql.org/ Website] eingesehen werden.

Die Freigabe einer neuen Hauptversion erfolgt in der Regel jährlich, kleinere Korrekturversionen alle paar Monaten. Die kleineren Updates werden "Minor"-Updates, die großen jährlich erscheinenden "Major"-Updates genannt. "Minor"-Update erscheinen in der Regel gleichzeitig für alle unterstützten "Major"-Versionen. [http://www.postgresql.org/support/versioning Falls Sie dieses Thema interessiert sollten Sie hier weiterlesen.]

=== Wo bekomme ich Support für PostgreSQL? ===

Die PostgreSQL-Community bietet Unterstützung per Mailing-Liste. Die
Web-Seite http://www.postgresql.org/community/lists/ bietet einen
Überblick. Die Listen general und bugs bieten einen guten Einstieg.

Eine deutschsprachige Mailing-Liste gibt es hier:
http://archives.postgresql.org/pgsql-de-allgemein/.

Der wichtigsten IRC-Channel ist #postgresql auf Freenode
(irc.freenode.net). Unter UNIX/Linux können Sie mit z.B. irc -c
'#postgresql' "$USER" irc.freenode.net. daran teilnehmen. Auf Freenode
gibt es folgende Channels:
* #postgresql-es (spanisch)
* #postgresqlfr (französischen)
* #postgresql-br (brasilianischen)

Es gibt außerdem einen PostgreSQL-Channel bei EFNet.

Eine Liste von Unternehmen, die Support für PostgreSQL auf kommerzieller Basis leisten, kann unter http://www.postgresql.org/support/professional_support eingesehen werden.

=== Wie kann ich einen Fehlerbericht abgeben? ===

Nutzen Sie das Formular unter
http://www.postgresql.org/support/submitbug. Schauen Sie aber vorher
unter ftp://ftp.postgresql.org/pub/ nach, ob es mittlerweile eine
neuere PostgreSQL-Version gibt, in der der Fehler behoben wurde.

Bugs, die über das Formular bzw. eine der Mailing-Listen
bekanntgegeben wurden, erhalten typischerweise einer der folgenden
Reaktionen:

* es ist kein Bug, der Grund wird benannt
* es ist ein bereits bekannter Bug, der bereits auf der TODO-Liste aufgenommen wurde
* der Bug wurde in der aktuellen Version behoben
* der Bug wurde bereits behoben, befindet sich aber noch nicht in einer offiziell veröffentlichten Version
* es wird um eingehendere Informationen gebeten, z.B.:
** Betriebssystem
** PostgreSQL-Version
** reproduzierbares Fallbeispiel
** Debugging-Information
** Debugger-Backtrace-Ausgabe
* der Bug ist neu. Folgendes könnte passieren:
** ein Patch wird erstellt und in der nächsten Version eingebaut
** der Bug kann nicht sofort behoben werden und wird auf die TODO-Liste gesetzt

=== Wie erfahre ich von bekannten Bugs oder fehlenden Features? ===

PostgreSQL unterstützt eine erweiterte Teilmenge von SQL:2003. Siehe
unsere TODO-Liste unter http://www.postgresql.org/docs/faqs.TODO.html
für eine Auflistung der bekannten Bugs, fehlenden Features und
zukünftigen Pläne.

Eine Anfrage nach einem neuen Feature führt normalerweise zu einer der
folgenden Antworten:

* das Feature ist bereits auf der TODO-Liste
* das Feature ist nicht wünschenswert, weil:
** es vorhandene Funktionalität dupliziert, welche bereits dem SQL-Standard folgt
** es würde die Komplexität der Code-Basis erhöhen, ohne nennenswerte Vorteile zu bringen
** es wäre unsicher bzw. unzuverlässig
* das neue Feature wird der TODO-Liste hinzugefügt

PostgreSQL verwendet kein Bugtracking-System, da es sich als effizienter erwiesen hat, E-Mails direkt zu beantworten und die TODO-Liste aktuell zu halten. In der Praxis werden Bugs sehr schnell beseitigt, und diejenigen Bugs, die Auswirkungen auf eine große Anzahl von Nutzern haben, werden meist kurzfristig korrigiert. Der einzige Überblick über alle Änderungen, Verbesserungen und Korrekturen in einer PostgreSQL-Version befindet sich in den CVS-Log-Meldungen. Auch die Release-Notes listen nicht jede Änderung in der Software auf.

=== Welche Dokumentation ist für PostgreSQL verfügbar? ===

PostgreSQL bietet umfangreiche Dokumentation, darunter ein großes
Handbuch, man-Pages und einige kleine Testprogramme. Siehe das /doc-
Verzeichnis. Ausserdem sind alle Handbücher online unter
http://www.postgresql.org/docs/ verfügbar.

Zwei Bücher zu PostgreSQL sind online verfügbar unter
http://www.postgresql.org/docs/books/awbook.html und
http://www.commandprompt.com/ppbook/ .

Eine Liste lieferbarer PostgreSQL-Bücher befindet sich unter
http://www.postgresql.org/docs/books Diverse technische Artikel
befinden sich unter http://www.postgresql.org/docs/techdocs .

psql hat einige nützliche \d-Befehle, um Informationen über Typen,
Operatoren, Funktionen, Aggregate, usw. zu zeigen.

Die PostgreSQL-Website enthält noch mehr Dokumentation.

=== Wie kann ich SQL lernen? ===

Die oben erwähnten PostgreSQL-spezifische Bücher bieten einen guten
Einstieg. Viele PostgreSQL-Anwender mögen "The Practical SQL Handbook"
(Bowman et al., Addison Wesley). Andere dagegen mögen "The Complete
Reference SQL" (Groff et al., McGraw-Hill).

Es gibt ausserdem einige nützliche Online-Tutorials:

* http://www.intermedia.net/support/sql/sqltut.shtm
* http://sqlcourse.com
* http://www.w3schools.com/sql/default.asp
* http://mysite.verizon.net/Graeme_Birchall/id1.html

=== Wie kann ich im Entwicklerteam mitarbeiten? ===

Lesen Sie in der Entwickler-FAQ unter
[[Developer_FAQ | Developer FAQ]] nach.

=== Wie läuft PostgreSQL im Vergleich zu anderen Datenbanksystemen? ===

Es gibt verschiedene Methoden, Software zu messen: Eigenschaften,
Performanz, Zuverlässigkeit, Support und Preis.

==== Eigenschaften ====

PostgreSQL besitzt die meisten Eigenschaften - wie
Transaktionen, Unterabfragen (Subqueries), Trigger, Views,
referenzielle Integrität bei Fremdschlüsseln und verfeinertes
Locking - die bei großen kommerziellen DBMS vorhanden sind. Es
bietet außerdem einige anderen Eigenschaften, die diese nicht
immer haben, wie benutzerbestimmte Typen, Vererbung, Regeln,
und die Multi-Versionen-Steuerung zum Verringern
konkurrierender Locks.

==== Performanz ====
Die Performanz von PostgreSQL ist mit der von kommerziellen und
anderen Open-Source-Datenbanken vergleichbar. In manchen
Bereichen ist es schneller, in anderen langsamer. In der Regel
beträgt der Unterschied +/-10%.

==== Zuverlässigkeit ====
Es ist selbstredend, dass ein DBMS wertlos ist, wenn es nicht
zuverlässig arbeitet. Daher bemühen wir uns, nur streng
geprüften und beständigen Code freizugeben, der nur ein Minimum
an Programmfehlern aufweist. Jede Freigabe hat mindestens einen
Monat Betatest-Phase hinter sich, und unsere Freigabehistorie
beweist, dass wir stabile und solide Versionen freigeben, die
im Produktionsbetrieb genutzt werden können. Wir glauben, dass
wir im Vergleich mit anderer Datenbanksoftware vorteilhaft
dastehen.

==== Support ====
Unsere Mailinglisten bieten die Möglichkeit, gemeinsam mit
einer großen Gruppe von Entwicklern und Benutzern mögliche
Probleme zu lösen. Wir können nicht immer eine Fehlerbehebung
garantieren, kommerzielle DBMS tun dies aber auch nicht. Der
direkte Kontakt zur Entwickler- und Benutzergemeinschaft und
der Zugriff auf die Handbücher und den Quellcode ermöglicht
einen im Vergleich zu anderen DBMS höherwertigeren Support. Es
gibt jedoch auch Anbieter von kommerziellen Support-Leistungen
(siehe FAQ-Punkt 1.7).

==== Preis ====
PostgreSQL ist frei verfügbar, sowohl für die kommerzielle wie
auch für die nicht-kommerzielle Nutzung. Sie können den
PostgreSQL-Code ohne Einschränkungen (außer denjenigen, die in
der oben angegebene BSD-artigen Lizenz erwähnt werden) in Ihr
Produkt integrieren.

=== Kann PostgreSQL eingebettet (embedded) werden? ===
PostgreSQL basiert auf einer Server/Client-Architektur, diese benötigt separate Prozesse für jeden Klient und Server, hinzukommen auch noch weitere "Helfer-Prozesse" (z. B. für autovacuum und stats-collector). Zwar können einige "embedded-Architekturen" diese Anforderungen erfüllen, aber wenn der Datenbank-Prozess innerhalb des Applikations-Prozesses laufen muss, kann PostgreSQL nicht verwendet werden. Dazu sollte man leichtere Datenbanken nehmen.

=== Wie kann ich mich von einer Maillingliste abmelden? Wie verhindere ich es, dass ich doppelte E-Mails bekomme? ===
Majordomo ermöglicht es sich von allen Maillinglisten an- und abzumelden, ggf. müssen Sie sich zuerst ihr Majordomo-Passwort zuschicken lassen.
[http://mail.postgresql.org/mj/mj_wwwusr PostgreSQLs Majordomo erreichen Sie hier.]

Die PostgreSQL-Maillinglisten sind so konfiguriert, dass Antworten an den ursprünglichen Autor und an die Maillingliste verschickt werden. Somit soll erreicht werden dass Benutzer immer schnellstmöglichst eine Antwort erhalten können. Diese Einstellungen können Sie auch über die Konfiguration von Majordomo ändern, ändern Sie dafür die Einstellung für ''eliminatecc''. Sie können auch einstellen dass Sie selbst keine Antwort auf Ihre eigenen E-Mails bekommen, ändern sie dafür die Einstellung für ''selfcopy''.
[http://mail.postgresql.org/mj/mj_wwwusr PostgreSQLs Majordomo erreichen Sie hier.]

== Fragen zu Benutzerprogrammen ==

=== Welche Schnittstellen gibt es für PostgreSQL? ===

Die PostgreSQL-Installation stellt nur Schnittstellen für C und
Embedded C bereit. Alle weitere Schnittstellen sind unabhängige
Projekte, die einzeln heruntergeladen werden werden müssen. Diese
Trennung ermöglicht individuelle Entwickler-Teams und
Entwicklungszyklen für die jeweiligen Projekte.

Einige Programmiersprachen wie PHP haben eine PostgreSQL-
Schnittstelle bereits eingebaut. Schnittstellen für Sprachen wie Perl,
TCL, Python und viele anderen sind unter http://gborg.postgresql.org
im Bereich Drivers/Interfaces verfügbar sowie per Internet-Suche.

=== Wie kann man PostgreSQL in einer Website nutzen? ===

Eine nette Einführung zu datenbank-gestützten Webseiten kann unter
http://www.webreview.com (engl.) eingesehen werden.

Für die Web-Integration ist PHP eine ausgezeichnete Schnittstelle. PHP
gibt es bei http://www.php.net

Desweiteren bietet sich die Perl-Schnittstelle mit CGI.pm
oder mod_perl auch an.

=== Hat PostgreSQL eine grafische Benutzerschnittstelle? ===

Es gibt eine große Anzahl von GUI-Programmen für PostgreSQL - sowohl
kommerziell als auch Open-Source. [http://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools Eine englische Liste befindet sich hier.]

== Administrative Fragen ==

=== Wie installiere ich PostgreSQL woanders als in /usr/local/pgsql? ===

Bei der Ausführung von configure die Option --prefix mit dem Zielverzeichnis angeben.

=== Wie regle ich Zugriffe von anderen Rechnern? ===

PostgreSQL ist standardmäßig so eingestellt, dass Verbindungen nur vom
lokalen Rechner über Unix Domain Sockets bzw. TCP/IP möglich sind.
Verbindungen von anderen Rechnern werden erst dann ermöglicht, wenn
Sie in der Datei postgresql.conf die Einstellung listen_addresses
anpassen, in der Datei $PGDATA/pg_hba.conf host-basierte
Authentifizierung einschalten und den Server neu starten.

=== Wie kann ich eine bessere Performanz erreichen? ===

Es gibt drei große Bereiche, in denen Performanzverbesserungen erzielt
werden können:

==== Abfrageoptimierung ====
Die Modifizierung von Abfragen kann eine bessere Performanz erzielen:

* [http://www.postgresql.org/docs/current/interactive/indexes.html Erstellung von Indexen, einschliesslich partieller Indexe sowie Expressionsindexe]
* Einsatz von COPY anstelle multipler INSERT-Anweisungen
* Gruppierung von mehreren Abfragen innerhalb einer Transaktion, um Aufwand beim Abschluss von Transaktionen einzusparen
* Einsatz von CLUSTER beim Holen von einer großen Anzahl von Datenreihen aus einem Index
* Einsatz von LIMIT, um eine Untermenge der Abfragenergebnisse zurückzuliefern
* [http://www.postgresql.org/docs/current/interactive/sql-prepare.html Einsatz von vorbereiteten Befehlen (prepared queries)]
* Einsatz von ANALYZE, um die Datenbankstatistik für den Abfragenplaner aktuell zu halten
* [http://www.postgresql.org/docs/current/static/routine-vacuuming.html Regelmäßiger Einsatz von VACUUM bzw. pg_autovacuum (autovacuum ist seit Version 8.3 standardmäßig aktiviert)]
* Bei großen Datenveränderungen die Löschung von Indexen

==== Server-Konfiguration ====
Einige Einstellungen in der Datei postgresql.conf wirken sich auf die Performanz aus. Das Handbuch enthält unter http://www.postgresql.org/docs/current/static/runtime-config.html eine komplette Auflistung.

Kommentare zu den jeweiligen Einstellungen gibt es unter http://www.varlena.com/varlena/GeneralBits/Tidbitsannotated_conf_e.html und http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html.

==== Hardware-Auswahl ====
Die Auswirkung von Hardware auf Performanz wird unter http://momjian.us/main/writings/pgsql/hw_performance/index.html und http://www.powerpostgresql.com/PerfList/ erläutert.

=== Welche Debugging-Funktionen sind für PostgreSQL verfügbar? ===

Unter den Optionen für die Server-Konfigurierung gibt es zahlreiche
log_*-Variablen, die die Ausgabe von Abfrage- und Prozessstatistiken
ermöglichen. Diese können für Debugging-Zwecke sowie Performanz-Tests
sehr nützlich sein.

=== Ich bekomme die Meldung "Sorry, too many clients", wenn ich eine Verbindung aufzubauen versuche. Warum? ===

Ihr System hat die maximal zulässige Anzahl von Datenbankverbindungen
erreicht (Voreinstellung 100). Sie müssen die maximale Anzahl der
gleichzeitig ausführbaren Backend-Prozesse hochsetzen, indem Sie in
postgresql.conf den Wert max_connections ändern und den Server
neustarten.

=== Wie wird PostgreSQL aktualisiert? ===

Allgemeine Informationen zur Aktualisierung von PostgreSQL gibt es auf
der Seite http://www.postgresql.org/support/versioning. Detaillierte
technische Informationen gibt es auf der Seite
http://www.postgresql.org/docs/current/static/install-upgrading.html

=== Kommt PostgreSQL mit den Anpassungen der Sommerzeit in verschiedenen Ländern klar? ===

Für die Berücksichtigung der Sommerzeit verwendet PostgreSQL Seit dem Release 8.0 die weiterverbreitete tzdata-Datenbank (auch bekannt als "zoneinfo database" oder "[http://www.twinsun.com/tz/tz-link.htm Olzen timezone database]".

Jedes Update von PostgreSQL beinhaltet die aktuellen tzdata Dateien, daher sollte es reichen die Minor-Updates der eingesetzten Major Version im Auge zu behalten.

Unter der Vorraussetzung dass das Betriebssystem diese Dateien schon in einer stets aktuellen Version vorbehält, ist es üblich, dass man diese Dateien verwendet. PostgreSQL bietet dazu eine compile-option an.

=== Welche Hardware eignet sich für den Betrieb mit PostgreSQL? ===

PostgreSQL läuft auf fast jeder Hardware-Kombination. Im PC-Bereich
gibt es allerdings sehr große Abweichungen in der Qualität. Für einen
Arbeitsplatz- oder Entwicklungsrechner mag dies nicht so bedeutend
sein, im Server-Betrieb jedoch lohnt sich auf jeden Fall die
Investition in teurere Bestandteile (Stichwörter ECC-Speicher, SCSI,
Hauptplatinen und Netzteile von namhaften Herstellern). Nutzen Sie
unsere Mailing-Listen, um Hardware-Optionen zu diskutieren.

== Fragen zum Betrieb ==

=== Wie wähle ich per SELECT-Anweisung nur die ersten paar Zeilen bzw. eine beliebige Zeile in einer Abfrage aus? ===

Wenn Sie bei der Ausführung der Abfrage die Anzahl der anzufordenden
Reihen bereits kennen, nutzen Sie LIMIT. Wenn die ORDER BY- Anweisung
mit einem Index verwendet wird, ist es möglich, dass die gesamte
Abfrage nicht ausgeführt werden muss. Wenn Sie die Anzahl der der
anzufordenden Reihen nicht kennen, verwenden Sie einen Cursor und
FETCH.

Um eine beliebige Zeile auszuwählen, nutzen Sie ORDER BY random():
SELECT spalte
FROM tabelle
ORDER BY random()
LIMIT 1

=== Wie finde ich heraus, welche Tabellen, Indexe, Datenbanken oder Benutzer in der Datenbank definiert sind? Wie bekomme ich die von psql verwendeten Abfragen? ===

In psql zeigt der Befehl \dt eine Liste der Datenbanktabellen. Weitere
psql-Befehle lassen sich mit \? anzeigen. Sie können sich die Datei
pgsql/src/bin/psql/describe.c mit dem Quellcode für psql ansehen. Sie
enthält die SQL-Abfragen, die die Backslash-Kommandos (\) ausführen.
Sie können psql auch mit der -E Option starten. Danach gibt psql die
Abfragen aus, die es bei der Ausführung der Befehle benutzt. Außerdem
biete PostgreSQL ein SQL-kompatibles INFORMATION SCHEMA, das
Metainformation über die Datenbank zur Verfügung stellt.

Mit psql -l können Sie alle Datenbanken anzeigen lassen.

Die Datei pgsql/src/tutorial/syscat.source enthält außerdem viele
SELECT- Abfragen, mit deren Hilfe man Information über die
Systemtabellen erhalten kann.

=== Wie ändere ich den Datentyp einer Spalte? ===

Ab Version 8.0 kann der Datentyp einer Spalte mit ALTER TABLE ALTER
COLUMN TYPE geändert werden, sofern der neue Datentyp die Werte des
alten Datentype aufnehmen kann.

Bei früheren Versionen gehen Sie wie folgt vor:
BEGIN;
ALTER TABLE tabelle ADD COLUMN neue_spalte neuer_datentyp;
UPDATE tabelle SET neue_spalte = CAST(alte_spalte AS neuer_datentyp);
ALTER TABLE tabelle DROP COLUMN alte_spalte;
COMMIT;

Um den Speicherplatz freizugeben, der von der gelöschten Spalte
verwendet wurde, führen Sie VACUUM FULL aus.

=== Was ist die Maximalgröße für eine Zeile, eine Tabelle, eine Datenbank? ===

Es bestehen folgende Obergrenzen:
Maximale Größe eine Datenbank? unbeschränkt (es existieren
Datenbanken mit 32 TB)
Maximale Größe einer Tabelle? 32 TB
Maximale Größe einer Zeile? 400 GB
Maximale Größe einer Spalte? 1 GB
Maximale Anzahl von Zeilen in einer Tabelle?
unbeschränkt
Maximale Anzahl von Spalten in einer Tabelle?
250-1600 je nach Spaltentyp
Maximale Anzahl von Indexen für eine Tabelle?
unbeschränkt

Selbstverständlich sind dies theoretische Werte, die oft durch die
verfügbaren Platten- und Speicherressourcen beschränkt werden. Extreme
Größen können zu Leistungseinbußen führen.

Die maximale Tabellengröße von 32 TB benötigt keine
Large-File-Unterstützung im Betriebssystem. Große Tabellen werden in
Dateien mit einer Größe von je 1 GB aufgeteilt, wodurch etwaige
dateisystem-bedingte Beschränkungen nicht relevant sind.

Die maximale Tabellengröße und die maximale Anzahl von Spalten können
vervierfacht werden, indem man die Default-Blockgröße auf 32 KB
heraufsetzt. Die Tabellengröße kann auch durch Tabellenpartitionierung
vergrößert werden.

Eine Einschränkung ist, dass Indexe nur auf Spalten erstellt werden
können, die bis etwa 2.000 Zeichen groß sind. Um auf größere Spalten
eine UNIQUE-Constraint setzen zu können, nutzen Sie einen funktionalen
Index mit dem MD5-Hash-Wert der Spalte. Um innerhalb einer großen, mit
Text belegten Spalte suchen zu können, verwenden Sie einen
Volltext-Index.

=== Wieviel Plattenplatz wird benötigt, um die Daten aus einer typischen Textdatei abzuspeichern? ===

Eine PostgreSQL-Datenbank kann beim Abspeichern einer einfachen
Textdatei bis zu fünfmal mehr Platz gegenüber der eigentlichen Größe
der Datei beanspruchen.

Betrachten wir eine Datei mit 100.000 Zeilen mit einem Integer und
einer Textbeschreibung pro Zeile. Gehen wir davon aus, dass die
durchschnittliche Länge der Textbeschreibung 20 Byte beträgt. Die
einfache Datei würde 2,8 MB groß sein. Die Größe der
PostgreSQL-Datenbankdatei, die diese Daten enthält, liegt ungefähr bei
5,2 MB:
24 Bytes: jeder Zeilenkopf (ungefähr)
+24 Bytes: ein Integer-Feld und ein Textfeld
+ 4 Bytes: Zeiger auf der Datenseite auf den Tupel
-----------------------------------------------
52 Bytes pro Zeile

Die Größe einer Datenseite in PostgreSQL beträgt 8192 Bytes (8 KB),
also:
8192 Bytes pro Seite
--------------------- = 146 Zeilen pro Seite (abgerundet)
52 Bytes pro Zeile

100.000 Datenzeilen
------------------------ = 685 Datenbankseiten (aufgerundet)
158 Zeilen pro Seite

633 Datenbankseiten * 8192 Bytes pro Seite = 5,185,536 bytes (5,2 MB)

Indexe beanspruchen nicht so viel Platz. Da sie jedoch die Daten
beinhalten, die sie indizieren, können auch sie sehr groß werden.

NULL-Werte werden als Bitmaps gespeichert, wodurch sie sehr wenig
Platz in Anspruch nehmen.

=== Meine Abfragen sind langsam oder benutzen die Indexe nicht. Warum? ===

Indexe werden nicht automatisch bei jeder Abfrage verwendet. Indexe
werden nur dann verwendet, wenn die abzufragende Tabelle eine
bestimmte Größe übersteigt, und die Abfrage nur eine kleine
Prozentzahl der Tabellenzeilen abfragt. Der Grund hierfür ist der,
dass die durch einen Index verursachten Festplattenzugriffe manchmal
länger dauern würden als ein einfaches Auslesen aller Tabellenzeilen
(sequentieller Scan).

Um festzustellen, ob ein Index verwendet werden soll, braucht
PostgreSQL Statistiken über die Tabelle. Diese Statistiken werden
durch die Anweisungen VACUUM ANALYZE bzw. ANALYZE berechnet. Anhand
der Statistiken kennt der Abfragenoptimierer die Anzahl der
Tabellenzeilen und kann besser entscheiden, ob Indexe verwendet werden
sollen. Statistiken sind auch bei der Ermittlung der optimalen
JOIN-Reihenfolgen und -Methoden wertvoll. Daher sollten diese
regelmässig durchgeführt werden, da sich der Inhalt einer Tabelle ja
auch verändert.

Indexe werden normalerweise nicht in ORDER BY-Abfrage oder in JOINs
verwendet. Ein sequentieller Scan mit anschließendem explizitem
Sortiervorgang ist normalerweise schneller als ein Index-Scan einer
großen Tabelle. Jedoch wird bei einer Abfrage, in der LIMIT zusammen
mit ORDER BY verwendet wird, oftmals ein Index verwendet, da nur ein
kleiner Abschnitt der Tabelle zurückgeliefert wird.

Sollte es danach aussehen, also ob der Optimierer irrtümlich einen
sequentiellen Scan ausführt, führen Sie SET enable_seqscan TO 'off'
aus und prüfen Sie, ob die Indexabfrage dadurch scheller geworden ist.

Bei der Nutzung von Wildcard-Operatoren wie LIKE oder ~, können Indexe
nur unter bestimmten Umständen verwendet werden:

* Das Suchmuster muss sich an Anfang des Strings befinden, d.h.:
** LIKE-Suchmuster dürfen nicht mit % anfangen;
** ~ (reguläre Ausdrücke) müssen mit ^ anfangen.
* Das Suchmuster darf nicht mit einer Zeichenklasse (z.B. [a-e]) beginnen.
* Suchmuster, die Gross- und Kleinschreibung nicht berücksichtigen (z.B. ILIKE bzw. ~*), verwenden keine Indexe. Stattdessen können funktionale Indexe verwendet werden, die im Punkt 4.8 beschrieben werden.
* Die Standard-Locale "C" muss während der Datenbank-Initialisierung mit initdb verwendet worden sein, da andere locales den nächstgrößten Wert nicht ermitteln können. Es ist allerdings möglich, einen besonderen text_pattern_ops-Index für solche Fälle zu erstellen.

In Versionen vor 8.0 werden Indexe oft nicht benutzt, wenn die
jeweiligen Datentypen nicht genau übereinstimmen. Dies gilt besonders
für Indexe auf Spalten mit den Datentypen INT2, INT8 und NUMERIC

=== Auf welche Weise kann ich sehen, wie der Abfrage-Optimierer meine Abfrage auswertet? ===

Eine ausführliche Erklärung zu diesem Thema findet sich in der [http://www.postgresql.org/docs/current/static/sql-explain.html EXPLAIN] Dokumentation.

=== Wie änder ich das Sortierverhalten von textähnlichen Daten? ===
PostgreSQL sortiert Daten anhand dem bei initdb gesetzten Locale. (Ab 8.4 wird es es möglich sein pro Datenbank ein eigenes Locale zu definieren)

Entspricht das Sortierverhalten nicht dem gewünschten muss man die Locale ändern. Die meisten Locales, außer "C", sortieren anhand der Reihenfolge des entsprechenden Wörterbuches. Das Locale "C" ignoriert jegliche Punktuation und Zwischenraum.

=== Wie verfahre ich bei der Suche mit regulären Ausdrücken und bei einer Suche, bei der Groß- und Kleinschreibweisen ignoriert werden? Wie verwende ich einen Index bei solchen Suchabfragen? ===

Der Operator ~ wendet einen regulären Ausdruck an und ~* wendet ihn
an, ohne die Groß- und Kleinschreibung zu beachten. Ebenso beachtet
LIKE die Groß- und Kleinschreibung, und ILIKE nicht.

Gleichheitsvergleiche, die Groß- und Kleinschreibung ignorieren,
werden in der Regel so ausgedruckt:
SELECT *
FROM tabelle
WHERE LOWER(spalte) = 'abc'

Hier wird kein normaler Index benutzt. Legt man hingegen einen
funktionalen Index an, so wird er auf jeden Fall verwendet:
CREATE INDEX tabelle_index ON tabelle (LOWER(spalte))

Falls der obige Index als einen UNIQUE-Index angelegt wird, können
keine Werte in die Spalte eingefügt werden, die sich nur durch ihre
Groß- und Kleinschreibung unterscheiden. Um Fehler zu vermeiden muß
ein CHECK-Constraint oder ein Trigger eingesetzt werden.

=== Wie ermittle ich in einer Abfrage, ob ein Feld NULL ist? Kann nach der NULL-Belegung sortiert werden? ===

Testen Sie die Spalte mit IS NULL bzw. IS NOT NULL.
SELECT
*
FROM
tabelle
WHERE
spalte IS NULL

Beim konkatenieren mit einen NULL-Wert wir das Ergebnis auch NULL. Um dies zu verhindern verwenden Sie am besten [http://www.postgresql.org/docs/current/static/functions-conditional.html COALESCE()]
SELECT
COALESCE(col1, '') || COALESCE(col2, '')
FROM tab;

Um die Spalte danach zu sortieren, ob sie mit NULL belegt ist oder nicht, verwenden Sie die Bedingungen IS NULL bzw. IS NOT NULL in der ORDER BY-Klausel. Da Bedingungen, die wahr sind, höher als das Gegenteil sortiert werden, bewirkt die folgende Abfrage, dass die NULL-Spalten zuerst gelistet werden:
SELECT
*
FROM
tabelle
ORDER BY
(spalte IS NOT NULL)

Ab PostreSQL 8.3 und höher, ist es möglich das standardisierte NULLS FIRST/NULLS LAST zu verwenden um die Position der NULL-Werte im Ergebnis zu bestimmen. (bei FIRST stehen diese zu erst, bei LAST am Ende)
SELECT
*
FROM
tab
ORDER BY
col NULLS FIRST;

=== Was ist der Unterschied zwischen den verschiedenen CHAR-Typen? ===
{| border="1"
!Typ
!interner Name
!Bemerkungen
|-
|VARCHAR(n)
|varchar
|die Größe legt die Maximallänge fest; kein Auffüllen mit Leerzeichen
|-
|CHAR(n)
|bpchar
|mit Leerzeichen gefüllt bis zur angegebenen Länge
|-
|TEXT
|text
|keine obere Grenze für die Länge
|-
|BYTEA
|bytea
|Bytearray mit variabler Länge (auch für '\0'-Bytes geeignet)
|-
|"char" (with the quotes)
|char
|ein Zeichen
|}

Der interne Name kommt vor allem in den Systemkatalogen und in manchen
Fehlermeldungen vor.

Die ersten vier Typen sind "varlena"-Typen (d.h. die ersten vier Bytes
geben die Länge an, gefolgt von den Daten). Daher ist der tatsächlich
belegte Platz immer etwas mehr als die deklarierte Feldgröße.
Allerdings wird unter Umständen auf diese Datentypen Datenkompression
durch das TOAST- Verfahren angewendet, womit der tatsächlich belegte
Platz auch geringer als erwartet ausfallen kann.

Für die Speicherung von Zeichenketten variabler Länge empfiehlt sich
VARCHAR(n). Die maximale Länge eines VARCHAR(n)-Felds wird bei der
Tabellendefinition festgelegt. TEXT setzt keine Längengrenze,
allerdings gibt es eine systembedingte Obergrenze von 1 GB.

CHAR(n) ist geeignet für die Speicherung von Zeichenketten, die alle
die gleiche Länge haben. Bitte beachten Sie, dass CHAR(n) automatisch
Zeichenketten bis zur definierten Feldlänge mit Leerzeichen ausfüllt,
während bei VARCHAR(n) nur die tatsächlich eingegebene Zeichenkette
gespeichert wird.

BYTEA ist für binäre Daten, besonders für Werte, die NULL-Bytes haben.

Alle der hier erwähnten Typen weisen ähnliche Performanzeigenschaften
auf.

=== Wie erzeuge ich ein serielles Feld mit automatischer Erhöhung des Wert? ===

PostgreSQL bietet einen SERIAL-Datentyp. Dies ist zwar kein richtiger Datentyp. Es ist die Kurzform für das Erstellen einer Spalte vom Typ Integer, die von einer Sequenz befüllt wird.

Zum Beispiel:
CREATE TABLE person (
id SERIAL,
name TEXT
)

wird automatisch in:
CREATE SEQUENCE person_id_seq;
CREATE TABLE person (
id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
name TEXT
);

umgewandelt.

Die automatisch generierte Sequenz besitzt immer folgenden Namen:
''tabellederspalte''-''namederspalte''_seq

Die Man-Page zu CREATE SEQUENCE beinhaltet mehr Informationen zu Sequenzen.

Es gibt auch einen Typ BIGSERIAL, dieser unterscheidet sich aber nur darin dass die Spalte den Typ BIGINTEGER bekommt. BIGSERIAL sollte verwendet werden wenn es zu erwarten ist, dass mehr als 2 Milliarden Sequenz-Werte verwendet werden.

=== Wie bekomme ich den Wert einer SERIAL-Sequenz? ===

Eine Möglichkeit wäre, mit der nextval()-Funktion den nächsten SERIAL-Wert von dem Sequenzobjekt vor der Auszuführung einer INSERT-Anweisung anzufordern und ihn dann explizit in die INSERT-Anweisung einzubinden. Anhand der Beispieltabelle in 4.11.1 könnte dieser Vorgang in einer Pseudosprache so aussehen:

new_id = output of execute("SELECT nextval('person_id_seq')");
execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");

Danach stünde der neue Wert in der Variablen new_id für die Verwendung in weiteren Abfragen zur Verfügung, zum Beispiel als Fremdschlüssel zur Tabelle 'person'). Bitte beachten Sie, dass der Name des automatisch erstellten SEQUENCE-Objektes folgenden Name hat: «table»_«serialcolumn»_seq wobei 'table' und 'serialcolumn' die Namen
der jeweils betreffenden Tabelle / Spalte darstellen.

Als weitere Möglichkeit können Sie nach einer INSERT-Anweisung den automatisch eingefügten SERIAL-Wert mit der currval()-Funktion zurückgeben lassen:

execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
new_id = output of execute("SELECT currval('person_id_seq')");

Die einfachste Möglichkeit ist es RETURNING zu verwenden. Ein einfaches Beispiel sähe so aus:
INSERT INTO person (name) VALUES ('Blaise Pascal') RETURNING id;

=== Führt currval() zu einer Race-Condition mit anderen Nutzern? ===

Nein. currval() liefert einen Wert zurück, der von Ihrer
Datenbank-Session bestimmt wird, und der anderen Sessionen nicht zur
Verfügung steht.

=== Warum werden die Sequenzwerte nach einem Transaktionsabbruch nicht zurückgesetzt? Warum gibt es Lücken in der Nummerierung meiner Sequenz-/SERIAL-Spalte? ===

Um die gleichzeitige Abarbeitung von Transaktionen zu verbessern,
werden Sequenzen gerade nicht für andere Transaktionen gesperrt,
sondern die Sequenznummern werden den laufenden Transaktionen sofort
zugeteilt. Lücken in der Sequenznummerierung werden durch abgebrochene
Transaktionen verursacht.

=== Was ist ein OID? ===

Jede Zeile, die in PostgreSQL erzeugt wird, bekommt eine eindeutige OID, sofern die Tabelle nicht mit der Option WITHOUT OIDS angelegt wurde. OIDs sind automatisch zugewiesene 4-Byte-Integer, die innerhalb der gesamten Datenbank einmalig sind. Allerdings laufen sie bei einem Wert von ungefähr 4 Milliarden über. PostgreSQL verwendet OIDs, um
seine interne Systemtabellen zu verbinden.

Um einmalige Idenfikatoren in Datentabellen zu erstellen, wird allerdings empfohlen, statt OIDs Werte zu verwenden, die von SERIAL-Sequenzen erzeugt werden. SERIAL-Sequenzen sind innerhalb einer Tabelle einmalig und daher weniger anfällig für Überläufe. Außerdem können 8-Byte-Sequenzwerte mit BIGSERIAL (SERIAL8) erzeugt werden.

=== Was ist ein CTID? ===

CTIDs werden benutzt, um bestimmte physikalische Zeilen durch Block und Offset Werte zu identifizieren. CTIDs verändern sich, sobald Zeilen verändert oder zurückgeladen werden. Sie werden in Indexeinträgen benutzt um auf die physikalischen Zeilen zu zeigen.

=== Wieso bekomme ich einen Fehler: "ERROR: Memory exhausted in AllocSetAlloc()"? ===

Wahrscheinlich gibt es keinen virtuellen Speicher mehr in Ihrem System
oder Ihr Kernel hat niedrige Höchstgrenzen für bestimmte Ressourcen.
Probieren Sie vor dem Start von postmaster folgendes:
ulimit -d 262144
limit datasize 256m

Je nach benutzter Shell wird nur einer dieser Befehle erfolgreich
ausgeführt werden. Auf jedem Fall wird die Grenze des Datensegments
für Prozesse erhöht werden und eventuell die erfolgreiche Ausführung
der Abfrage ermöglichen. Falls Sie ein Problem mit dem SQL-Client
haben, weil das Backend zu viele Daten zurückliefert, versuchen Sie
dies vor dem Start des SQL-Clients.

=== Wie kann ich feststellen, welche PostgreSQL-Version bei mir läuft? ===

Geben Sie in psql SELECT VERSION(); ein.

=== Wie kann ich eine Spalte erstellen, deren Default-Wert immer die aktuelle Uhrzeit enthalten soll? ===

Dazu verwenden Sie CURRENT_TIMESTAMP:
CREATE TABLE test (x INT, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

=== Wie führe ich eine OUTER JOIN durch? ===

PostgreSQL unterstützt OUTER JOINs nach dem SQL- Standardsyntax. Hier
zwei Beispiele:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 ON (t1.spalte = t2.spalte)

bzw.:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 USING (spalte)

Diese identischen Abfragen verknüpfen tabelle_1 mit tabelle_2 über die
Spalte 'spalte' und geben außerdem alle unverknüpften Zeilen in
tabelle_1 (diejenigen, die keine Entsprechung in tabelle_2 haben)
zurück. Ein RIGHT JOIN würde hingegen alle unverknüpften Zeilen in
tabelle_2 hinzufügen und ein FULL JOIN würde alle verknüpften Zeilen
sowie jeweils alle unverknüpften Zeilen aus den beiden Tabellen
zurückliefern. Die Angabe von OUTER ist nicht zwingend und kann in
LEFT, RIGHT und FULL-Verknüpfungen weggelassen werden. Normale
Verknüpfungen sind INNER JOINs.

=== Wie kann ich Abfragen über mehrere Datenbanken hinweg ausführen? ===

Es gibt keinen Weg, innerhalb einer Abfrage auf mehr als eine
Datenbank zuzugreifen. Da PostgreSQL datenbank-spezifische
Systemkataloge lädt, ist eine datenbankübergreifende Abfrage nicht
möglich.

contrib/dblink ist eine Erweiterung, die datenbankübergreifende
Abfragen über Funktionsaufrufe ermöglicht.

=== Wie kann ich mehrere Zeilen bzw. Spalten von einer Funktion zurückgeben lassen? ===

Funktionen können mehrere Zeilen und Spalten zurückgeben, vgl.:
http://www.postgresql.org/docs/techdocs.17.

=== Warum bekomme ich eine Fehlermeldung wie "relation with OID ##### does not exist" wenn ich temporäre Tabellen in PL/PgSQL-Funktionen benutze? ===

In PostgreSQL-Versionen vor 8.3 verarbeitet PL/PgSQL Funktionen in
einer Cache. Dies hat eine unangenehme Nebenwirkung, nämlich dass wenn
eine PL/PgSQL-Funktion auf eine temporäre Tabelle zugreift, und diese
Tabelle anschließend gelöscht bzw. neu erstellt wird, die Funktion
fehlschlagen wird, da die gecachten Funktionsinhalte noch auf die alte
temporäre Tabelle zeigen. Die Lösung für diese Probleme besteht darin,
in der PL/PgSQL- Funktion mittels EXECUTE auf temporäre Tabellen
zuzugreifen. Dies bewirkt, dass bei jedem Funktionsruf die betreffende
Abfrage neu geparst wird.

Dieses Problem taucht in PostgreSQL 8.3 und späteren Versionen nicht
mehr auf.

=== Welche Replikationslösungen gibt es? ===

Der Begriff "replikation" umfasst mehrere verschiedene Technologien,
jede mit eigenen Vor- und Nachteilen. [http://www.postgresql.org/docs/8.3/static/high-availability.html Die Dokumentation enthält eine gute Einführung in das Thema Replikation]

Mit "Master/slave"-Replikation werden Änderungen in einer
Hauptdatenbank durchgeführt und an "Sklaven" verteilt, die im
Nur-Lese-Modus arbeiten. Die populärste Lösung für PostgreSQL ist
Slony-I.

"Multi-master replication" ermöglicht sowohl lesende als auch
schreibende Zugriffe über mehrere Datenbank-Server hinweg. Allerdings
hat diese Art von Replikation eine negative Auswirkung auf die
Performanz durch die Notwendigkeit, Änderungen zwischen Servern zu
synchronisieren. Pgcluster ist die populärste freie Lösung für
PostgreSQL.

Es gibt auch einige kommerzielle und hardware-basierte
Replikationslösungen für verschiedene Arten der Replikation.

=== Warum werden die Tabellen- und Spaltennamen in meiner Abfrage nicht erkannt? Warum werden Großbuchstaben umgewandelt? ===

Die häufigste Ursache ist die Verwendung von Gänsefüßchen bei der
Anlegung von Tabellen, z.B.:
CREATE TABLE "Tabelle"
("SPALTE1" INT)

Dadurch werden Tabellen- und Spaltennamen (sog. Identifikatoren) in
genau der Schreibweise gespeichert (vgl. Dokumentation), was dazu
führt, dass man sie danach immer in Gänsefüßchen angeben muss. Im
obigen Beispiel muss man also immer etwa SELECT * FROM "Tabelle"
verwenden. Um dieses Problem zu vermeiden, müssen Sie immer eines der
folgenden Punkte beachten:

* bei der Tabellenanlegung keine Gänsefüßchen verwenden;
* in Identifikatoren nur Kleinschreibung verwenden;
* immer Identifikatoren mit Gänsefüßchen versehen

== Anmerkungen des Übersetzers ==

Die englische Vorlage dieser FAQ wird ständig überarbeitet. Daher
liegt die Übersetzung nicht immer auf dem aktuellsten Stand.

Die aktuellste Version der deutschen Übersetzung befindet sich immer
unter http://sql-info.de/postgresql/FAQ_german.html. Diese
"Arbeitsversion" enthält eventuell Änderungen, die noch nicht auf der
PostgreSQL-Website eingebunden worden sind.

Über Verbesserungshinweise und Korrekturvorschläge sowie
Verständnisfragen zum Inhalt der FAQ freue ich mich. Ich nehme auch
allgemeine Fragen zu PostgreSQL gerne entgegen, verweise jedoch auf
die Mailing-Listen als schnelle und zuverlässige Anlaufstellen.

[[Category:FAQ]]

FAQ/de

2011-12-06T18:41:51Z

Mastermind: /* Welche Replikationslösungen gibt es? */

{{Languages}}

== Allgemeine Fragen ==

=== Was ist PostgreSQL? Wie wird es ausgesprochen? ===

Die (englische) Aussprache ist "Post-Gres-Q-L". Im allgemeinen
Sprachgebrauch hat sich die Kurzform "Postgres" auch durchgesetzt.
(Für diejenigen, die es interessiert: eine MP3-Datei mit der
amerikanischen Aussprache befindet sich hier:
http://www.postgresql.org/files/postgresql.mp3

PostgreSQL ist ein objektrelationales Datenbanksystem, das die Vorzüge
von kommerziellen Datenbanksystemen mit zukunftsweisenden Innovationen
kombiniert. PostgreSQL ist freie Software und dessen kompletter
Quellcode ist öffentlich verfügbar.

Die PostgreSQL-Entwicklung wird von einem Team von meist freiwilligen
Entwicklern durchgeführt. Dieses Team ist für die Gesamtentwicklung
von PostgreSQL verantwortlich. Es handelt sich um ein
Gemeinschaftsprojekt, das nicht von einer bestimmten Firma
kontrolliert wird. Lesen Sie die Entwickler-FAQ:
http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn Sie an einer
Mitarbeit interessiert sind.

=== Wer kontrolliert PostgreSQL? ===

Falls Sie nach dem Namen eines etwaigen Inhabers bzw. nach einem
allmächtigen Zentralkommittee suchen - sparen Sie sich die Mühe, sowas
existiert gar nicht. Es gibt zwar das "Core Committee" sowie
Entwickler, die CVS-Schreibberechtigung haben, jedoch haben diese
Gruppen eher nur eine administrative Rolle. Das Projekt wird durch die
Community gesteuert, die aus den Entwicklern sowie natürlich auch den
Nutzern besteht - jeder kann daran teilnehmen. (Lesen Sie die
Entwickler-FAQ: http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn
Sie an der PostgreSQL-Entwicklung teilnehmen möchten).

=== Welchem Copyright unterliegt PostgreSQL? ===

PostgreSQL wird unter der klassischen BSD-Lizenz herausgegeben. Im
Grunde genommen erlaubt diese den Nutzern, beliebig mit dem Code
umzugehen, auch der Weiterverkauf von Binärversionen ohne Quellcode
ist erlaubt. Die einzige Einschränkung besteht darin, dass PostgreSQL
auf keinen Fall für etwaige Probleme mit der Software haftet. Außerdem
muß der Copyright- Text in allen Kopien der Software enthalten sein.
Dies ist der Originaltext der BSD-Lizenz:

PostgreSQL Data Base Management System

Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group
Portions Copyright (c) 1994-6 Regents of the University of California

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose, without fee, and without a written
agreement is hereby granted, provided that the above copyright notice
and this paragraph and the following two paragraphs appear in all
copies.

IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY
FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES,
INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND
ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE
PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF
CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT,
UPDATES, ENHANCEMENTS, OR MODIFICATIONS.

Es gilt die Copyright-Klausel im Original!

=== Auf welchen Plattformen läuft PostgreSQL? ===

Normalerweise kann PostgreSQL auf jeder modernen UNIX-kompatiblen
Plattform eingesetzt werden. Diejenigen Plattformen, die bei der
jeweiligen Versionsfreigabe getestet wurden, sind in den
Installationsanleitungen aufgelistet.

PostgreSQL läuft auch auf Microsoft NT-basierten Betriebssystemen wie
Windows 2000 SP4, XP und Server 2003. Ein vorgefertigtes
Installationspaket kann von http://pgfoundry.org/projects/pginstaller
heruntergeladen werden. DOS-basierte Windows-Versionen (Win95, Win98,
WinMe) können PostgreSQL nur mit Hilfe der Cygwin-Umgebung ausführen.

=== Woher bekomme ich PostgreSQL? ===

Per Web-Browser hier: http://www.postgresql.org/ftp/ und per FTP hier:
ftp://ftp.postgresql.org/pub/.

=== Was ist die neueste Version von PostgreSQL? ===

Die neueste Version von PostgreSQL kann auf der [http://www.postgresql.org/ Website] eingesehen werden.

Die Freigabe einer neuen Hauptversion erfolgt in der Regel jährlich, kleinere Korrekturversionen alle paar Monaten. Die kleineren Updates werden "Minor"-Updates, die großen jährlich erscheinenden "Major"-Updates genannt. "Minor"-Update erscheinen in der Regel gleichzeitig für alle unterstützten "Major"-Versionen. [http://www.postgresql.org/support/versioning Falls Sie dieses Thema interessiert sollten Sie hier weiterlesen.]

=== Wo bekomme ich Support für PostgreSQL? ===

Die PostgreSQL-Community bietet Unterstützung per Mailing-Liste. Die
Web-Seite http://www.postgresql.org/community/lists/ bietet einen
Überblick. Die Listen general und bugs bieten einen guten Einstieg.

Eine deutschsprachige Mailing-Liste gibt es hier:
http://archives.postgresql.org/pgsql-de-allgemein/.

Der wichtigsten IRC-Channel ist #postgresql auf Freenode
(irc.freenode.net). Unter UNIX/Linux können Sie mit z.B. irc -c
'#postgresql' "$USER" irc.freenode.net. daran teilnehmen. Auf Freenode
gibt es folgende Channels:
* #postgresql-es (spanisch)
* #postgresqlfr (französischen)
* #postgresql-br (brasilianischen)

Es gibt außerdem einen PostgreSQL-Channel bei EFNet.

Eine Liste von Unternehmen, die Support für PostgreSQL auf kommerzieller Basis leisten, kann unter http://www.postgresql.org/support/professional_support eingesehen werden.

=== Wie kann ich einen Fehlerbericht abgeben? ===

Nutzen Sie das Formular unter
http://www.postgresql.org/support/submitbug. Schauen Sie aber vorher
unter ftp://ftp.postgresql.org/pub/ nach, ob es mittlerweile eine
neuere PostgreSQL-Version gibt, in der der Fehler behoben wurde.

Bugs, die über das Formular bzw. eine der Mailing-Listen
bekanntgegeben wurden, erhalten typischerweise einer der folgenden
Reaktionen:

* es ist kein Bug, der Grund wird benannt
* es ist ein bereits bekannter Bug, der bereits auf der TODO-Liste aufgenommen wurde
* der Bug wurde in der aktuellen Version behoben
* der Bug wurde bereits behoben, befindet sich aber noch nicht in einer offiziell veröffentlichten Version
* es wird um eingehendere Informationen gebeten, z.B.:
** Betriebssystem
** PostgreSQL-Version
** reproduzierbares Fallbeispiel
** Debugging-Information
** Debugger-Backtrace-Ausgabe
* der Bug ist neu. Folgendes könnte passieren:
** ein Patch wird erstellt und in der nächsten Version eingebaut
** der Bug kann nicht sofort behoben werden und wird auf die TODO-Liste gesetzt

=== Wie erfahre ich von bekannten Bugs oder fehlenden Features? ===

PostgreSQL unterstützt eine erweiterte Teilmenge von SQL:2003. Siehe
unsere TODO-Liste unter http://www.postgresql.org/docs/faqs.TODO.html
für eine Auflistung der bekannten Bugs, fehlenden Features und
zukünftigen Pläne.

Eine Anfrage nach einem neuen Feature führt normalerweise zu einer der
folgenden Antworten:

* das Feature ist bereits auf der TODO-Liste
* das Feature ist nicht wünschenswert, weil:
** es vorhandene Funktionalität dupliziert, welche bereits dem SQL-Standard folgt
** es würde die Komplexität der Code-Basis erhöhen, ohne nennenswerte Vorteile zu bringen
** es wäre unsicher bzw. unzuverlässig
* das neue Feature wird der TODO-Liste hinzugefügt

PostgreSQL verwendet kein Bugtracking-System, da es sich als effizienter erwiesen hat, E-Mails direkt zu beantworten und die TODO-Liste aktuell zu halten. In der Praxis werden Bugs sehr schnell beseitigt, und diejenigen Bugs, die Auswirkungen auf eine große Anzahl von Nutzern haben, werden meist kurzfristig korrigiert. Der einzige Überblick über alle Änderungen, Verbesserungen und Korrekturen in einer PostgreSQL-Version befindet sich in den CVS-Log-Meldungen. Auch die Release-Notes listen nicht jede Änderung in der Software auf.

=== Welche Dokumentation ist für PostgreSQL verfügbar? ===

PostgreSQL bietet umfangreiche Dokumentation, darunter ein großes
Handbuch, man-Pages und einige kleine Testprogramme. Siehe das /doc-
Verzeichnis. Ausserdem sind alle Handbücher online unter
http://www.postgresql.org/docs/ verfügbar.

Zwei Bücher zu PostgreSQL sind online verfügbar unter
http://www.postgresql.org/docs/books/awbook.html und
http://www.commandprompt.com/ppbook/ .

Eine Liste lieferbarer PostgreSQL-Bücher befindet sich unter
http://www.postgresql.org/docs/books Diverse technische Artikel
befinden sich unter http://www.postgresql.org/docs/techdocs .

psql hat einige nützliche \d-Befehle, um Informationen über Typen,
Operatoren, Funktionen, Aggregate, usw. zu zeigen.

Die PostgreSQL-Website enthält noch mehr Dokumentation.

=== Wie kann ich SQL lernen? ===

Die oben erwähnten PostgreSQL-spezifische Bücher bieten einen guten
Einstieg. Viele PostgreSQL-Anwender mögen "The Practical SQL Handbook"
(Bowman et al., Addison Wesley). Andere dagegen mögen "The Complete
Reference SQL" (Groff et al., McGraw-Hill).

Es gibt ausserdem einige nützliche Online-Tutorials:

* http://www.intermedia.net/support/sql/sqltut.shtm
* http://sqlcourse.com
* http://www.w3schools.com/sql/default.asp
* http://mysite.verizon.net/Graeme_Birchall/id1.html

=== Wie kann ich im Entwicklerteam mitarbeiten? ===

Lesen Sie in der Entwickler-FAQ unter
[[Developer_FAQ | Developer FAQ]] nach.

=== Wie läuft PostgreSQL im Vergleich zu anderen Datenbanksystemen? ===

Es gibt verschiedene Methoden, Software zu messen: Eigenschaften,
Performanz, Zuverlässigkeit, Support und Preis.

==== Eigenschaften ====

PostgreSQL besitzt die meisten Eigenschaften - wie
Transaktionen, Unterabfragen (Subqueries), Trigger, Views,
referenzielle Integrität bei Fremdschlüsseln und verfeinertes
Locking - die bei großen kommerziellen DBMS vorhanden sind. Es
bietet außerdem einige anderen Eigenschaften, die diese nicht
immer haben, wie benutzerbestimmte Typen, Vererbung, Regeln,
und die Multi-Versionen-Steuerung zum Verringern
konkurrierender Locks.

==== Performanz ====
Die Performanz von PostgreSQL ist mit der von kommerziellen und
anderen Open-Source-Datenbanken vergleichbar. In manchen
Bereichen ist es schneller, in anderen langsamer. In der Regel
beträgt der Unterschied +/-10%.

==== Zuverlässigkeit ====
Es ist selbstredend, dass ein DBMS wertlos ist, wenn es nicht
zuverlässig arbeitet. Daher bemühen wir uns, nur streng
geprüften und beständigen Code freizugeben, der nur ein Minimum
an Programmfehlern aufweist. Jede Freigabe hat mindestens einen
Monat Betatest-Phase hinter sich, und unsere Freigabehistorie
beweist, dass wir stabile und solide Versionen freigeben, die
im Produktionsbetrieb genutzt werden können. Wir glauben, dass
wir im Vergleich mit anderer Datenbanksoftware vorteilhaft
dastehen.

==== Support ====
Unsere Mailinglisten bieten die Möglichkeit, gemeinsam mit
einer großen Gruppe von Entwicklern und Benutzern mögliche
Probleme zu lösen. Wir können nicht immer eine Fehlerbehebung
garantieren, kommerzielle DBMS tun dies aber auch nicht. Der
direkte Kontakt zur Entwickler- und Benutzergemeinschaft und
der Zugriff auf die Handbücher und den Quellcode ermöglicht
einen im Vergleich zu anderen DBMS höherwertigeren Support. Es
gibt jedoch auch Anbieter von kommerziellen Support-Leistungen
(siehe FAQ-Punkt 1.7).

==== Preis ====
PostgreSQL ist frei verfügbar, sowohl für die kommerzielle wie
auch für die nicht-kommerzielle Nutzung. Sie können den
PostgreSQL-Code ohne Einschränkungen (außer denjenigen, die in
der oben angegebene BSD-artigen Lizenz erwähnt werden) in Ihr
Produkt integrieren.

=== Kann PostgreSQL eingebettet (embedded) werden? ===
PostgreSQL basiert auf einer Server/Client-Architektur, diese benötigt separate Prozesse für jeden Klient und Server, hinzukommen auch noch weitere "Helfer-Prozesse" (z. B. für autovacuum und stats-collector). Zwar können einige "embedded-Architekturen" diese Anforderungen erfüllen, aber wenn der Datenbank-Prozess innerhalb des Applikations-Prozesses laufen muss, kann PostgreSQL nicht verwendet werden. Dazu sollte man leichtere Datenbanken nehmen.

=== Wie kann ich mich von einer Maillingliste abmelden? Wie verhindere ich es, dass ich doppelte E-Mails bekomme? ===
Majordomo ermöglicht es sich von allen Maillinglisten an- und abzumelden, ggf. müssen Sie sich zuerst ihr Majordomo-Passwort zuschicken lassen.
[http://mail.postgresql.org/mj/mj_wwwusr PostgreSQLs Majordomo erreichen Sie hier.]

Die PostgreSQL-Maillinglisten sind so konfiguriert, dass Antworten an den ursprünglichen Autor und an die Maillingliste verschickt werden. Somit soll erreicht werden dass Benutzer immer schnellstmöglichst eine Antwort erhalten können. Diese Einstellungen können Sie auch über die Konfiguration von Majordomo ändern, ändern Sie dafür die Einstellung für ''eliminatecc''. Sie können auch einstellen dass Sie selbst keine Antwort auf Ihre eigenen E-Mails bekommen, ändern sie dafür die Einstellung für ''selfcopy''.
[http://mail.postgresql.org/mj/mj_wwwusr PostgreSQLs Majordomo erreichen Sie hier.]

== Fragen zu Benutzerprogrammen ==

=== Welche Schnittstellen gibt es für PostgreSQL? ===

Die PostgreSQL-Installation stellt nur Schnittstellen für C und
Embedded C bereit. Alle weitere Schnittstellen sind unabhängige
Projekte, die einzeln heruntergeladen werden werden müssen. Diese
Trennung ermöglicht individuelle Entwickler-Teams und
Entwicklungszyklen für die jeweiligen Projekte.

Einige Programmiersprachen wie PHP haben eine PostgreSQL-
Schnittstelle bereits eingebaut. Schnittstellen für Sprachen wie Perl,
TCL, Python und viele anderen sind unter http://gborg.postgresql.org
im Bereich Drivers/Interfaces verfügbar sowie per Internet-Suche.

=== Wie kann man PostgreSQL in einer Website nutzen? ===

Eine nette Einführung zu datenbank-gestützten Webseiten kann unter
http://www.webreview.com (engl.) eingesehen werden.

Für die Web-Integration ist PHP eine ausgezeichnete Schnittstelle. PHP
gibt es bei http://www.php.net

Desweiteren bietet sich die Perl-Schnittstelle mit CGI.pm
oder mod_perl auch an.

=== Hat PostgreSQL eine grafische Benutzerschnittstelle? ===

Es gibt eine große Anzahl von GUI-Programmen für PostgreSQL - sowohl
kommerziell als auch Open-Source. [http://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools Eine englische Liste befindet sich hier.]

== Administrative Fragen ==

=== Wie installiere ich PostgreSQL woanders als in /usr/local/pgsql? ===

Bei der Ausführung von configure die Option --prefix mit dem Zielverzeichnis angeben.

=== Wie regle ich Zugriffe von anderen Rechnern? ===

PostgreSQL ist standardmäßig so eingestellt, dass Verbindungen nur vom
lokalen Rechner über Unix Domain Sockets bzw. TCP/IP möglich sind.
Verbindungen von anderen Rechnern werden erst dann ermöglicht, wenn
Sie in der Datei postgresql.conf die Einstellung listen_addresses
anpassen, in der Datei $PGDATA/pg_hba.conf host-basierte
Authentifizierung einschalten und den Server neu starten.

=== Wie kann ich eine bessere Performanz erreichen? ===

Es gibt drei große Bereiche, in denen Performanzverbesserungen erzielt
werden können:

==== Abfrageoptimierung ====
Die Modifizierung von Abfragen kann eine bessere Performanz erzielen:

* [http://www.postgresql.org/docs/current/interactive/indexes.html Erstellung von Indexen, einschliesslich partieller Indexe sowie Expressionsindexe]
* Einsatz von COPY anstelle multipler INSERT-Anweisungen
* Gruppierung von mehreren Abfragen innerhalb einer Transaktion, um Aufwand beim Abschluss von Transaktionen einzusparen
* Einsatz von CLUSTER beim Holen von einer großen Anzahl von Datenreihen aus einem Index
* Einsatz von LIMIT, um eine Untermenge der Abfragenergebnisse zurückzuliefern
* [http://www.postgresql.org/docs/current/interactive/sql-prepare.html Einsatz von vorbereiteten Befehlen (prepared queries)]
* Einsatz von ANALYZE, um die Datenbankstatistik für den Abfragenplaner aktuell zu halten
* [http://www.postgresql.org/docs/current/static/routine-vacuuming.html Regelmäßiger Einsatz von VACUUM bzw. pg_autovacuum (autovacuum ist seit Version 8.3 standardmäßig aktiviert)]
* Bei großen Datenveränderungen die Löschung von Indexen

==== Server-Konfiguration ====
Einige Einstellungen in der Datei postgresql.conf wirken sich auf die Performanz aus. Das Handbuch enthält unter http://www.postgresql.org/docs/current/static/runtime-config.html eine komplette Auflistung.

Kommentare zu den jeweiligen Einstellungen gibt es unter http://www.varlena.com/varlena/GeneralBits/Tidbitsannotated_conf_e.html und http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html.

==== Hardware-Auswahl ====
Die Auswirkung von Hardware auf Performanz wird unter http://momjian.us/main/writings/pgsql/hw_performance/index.html und http://www.powerpostgresql.com/PerfList/ erläutert.

=== Welche Debugging-Funktionen sind für PostgreSQL verfügbar? ===

Unter den Optionen für die Server-Konfigurierung gibt es zahlreiche
log_*-Variablen, die die Ausgabe von Abfrage- und Prozessstatistiken
ermöglichen. Diese können für Debugging-Zwecke sowie Performanz-Tests
sehr nützlich sein.

=== Ich bekomme die Meldung "Sorry, too many clients", wenn ich eine Verbindung aufzubauen versuche. Warum? ===

Ihr System hat die maximal zulässige Anzahl von Datenbankverbindungen
erreicht (Voreinstellung 100). Sie müssen die maximale Anzahl der
gleichzeitig ausführbaren Backend-Prozesse hochsetzen, indem Sie in
postgresql.conf den Wert max_connections ändern und den Server
neustarten.

=== Wie wird PostgreSQL aktualisiert? ===

Allgemeine Informationen zur Aktualisierung von PostgreSQL gibt es auf
der Seite http://www.postgresql.org/support/versioning. Detaillierte
technische Informationen gibt es auf der Seite
http://www.postgresql.org/docs/current/static/install-upgrading.html

=== Kommt PostgreSQL mit den Anpassungen der Sommerzeit in verschiedenen Ländern klar? ===

Für die Berücksichtigung der Sommerzeit verwendet PostgreSQL Seit dem Release 8.0 die weiterverbreitete tzdata-Datenbank (auch bekannt als "zoneinfo database" oder "[http://www.twinsun.com/tz/tz-link.htm Olzen timezone database]".

Jedes Update von PostgreSQL beinhaltet die aktuellen tzdata Dateien, daher sollte es reichen die Minor-Updates der eingesetzten Major Version im Auge zu behalten.

Unter der Vorraussetzung dass das Betriebssystem diese Dateien schon in einer stets aktuellen Version vorbehält, ist es üblich, dass man diese Dateien verwendet. PostgreSQL bietet dazu eine compile-option an.

=== Welche Hardware eignet sich für den Betrieb mit PostgreSQL? ===

PostgreSQL läuft auf fast jeder Hardware-Kombination. Im PC-Bereich
gibt es allerdings sehr große Abweichungen in der Qualität. Für einen
Arbeitsplatz- oder Entwicklungsrechner mag dies nicht so bedeutend
sein, im Server-Betrieb jedoch lohnt sich auf jeden Fall die
Investition in teurere Bestandteile (Stichwörter ECC-Speicher, SCSI,
Hauptplatinen und Netzteile von namhaften Herstellern). Nutzen Sie
unsere Mailing-Listen, um Hardware-Optionen zu diskutieren.

== Fragen zum Betrieb ==

=== Wie wähle ich per SELECT-Anweisung nur die ersten paar Zeilen bzw. eine beliebige Zeile in einer Abfrage aus? ===

Wenn Sie bei der Ausführung der Abfrage die Anzahl der anzufordenden
Reihen bereits kennen, nutzen Sie LIMIT. Wenn die ORDER BY- Anweisung
mit einem Index verwendet wird, ist es möglich, dass die gesamte
Abfrage nicht ausgeführt werden muss. Wenn Sie die Anzahl der der
anzufordenden Reihen nicht kennen, verwenden Sie einen Cursor und
FETCH.

Um eine beliebige Zeile auszuwählen, nutzen Sie ORDER BY random():
SELECT spalte
FROM tabelle
ORDER BY random()
LIMIT 1

=== Wie finde ich heraus, welche Tabellen, Indexe, Datenbanken oder Benutzer in der Datenbank definiert sind? Wie bekomme ich die von psql verwendeten Abfragen? ===

In psql zeigt der Befehl \dt eine Liste der Datenbanktabellen. Weitere
psql-Befehle lassen sich mit \? anzeigen. Sie können sich die Datei
pgsql/src/bin/psql/describe.c mit dem Quellcode für psql ansehen. Sie
enthält die SQL-Abfragen, die die Backslash-Kommandos (\) ausführen.
Sie können psql auch mit der -E Option starten. Danach gibt psql die
Abfragen aus, die es bei der Ausführung der Befehle benutzt. Außerdem
biete PostgreSQL ein SQL-kompatibles INFORMATION SCHEMA, das
Metainformation über die Datenbank zur Verfügung stellt.

Mit psql -l können Sie alle Datenbanken anzeigen lassen.

Die Datei pgsql/src/tutorial/syscat.source enthält außerdem viele
SELECT- Abfragen, mit deren Hilfe man Information über die
Systemtabellen erhalten kann.

=== Wie ändere ich den Datentyp einer Spalte? ===

Ab Version 8.0 kann der Datentyp einer Spalte mit ALTER TABLE ALTER
COLUMN TYPE geändert werden, sofern der neue Datentyp die Werte des
alten Datentype aufnehmen kann.

Bei früheren Versionen gehen Sie wie folgt vor:
BEGIN;
ALTER TABLE tabelle ADD COLUMN neue_spalte neuer_datentyp;
UPDATE tabelle SET neue_spalte = CAST(alte_spalte AS neuer_datentyp);
ALTER TABLE tabelle DROP COLUMN alte_spalte;
COMMIT;

Um den Speicherplatz freizugeben, der von der gelöschten Spalte
verwendet wurde, führen Sie VACUUM FULL aus.

=== Was ist die Maximalgröße für eine Zeile, eine Tabelle, eine Datenbank? ===

Es bestehen folgende Obergrenzen:
Maximale Größe eine Datenbank? unbeschränkt (es existieren
Datenbanken mit 32 TB)
Maximale Größe einer Tabelle? 32 TB
Maximale Größe einer Zeile? 400 GB
Maximale Größe einer Spalte? 1 GB
Maximale Anzahl von Zeilen in einer Tabelle?
unbeschränkt
Maximale Anzahl von Spalten in einer Tabelle?
250-1600 je nach Spaltentyp
Maximale Anzahl von Indexen für eine Tabelle?
unbeschränkt

Selbstverständlich sind dies theoretische Werte, die oft durch die
verfügbaren Platten- und Speicherressourcen beschränkt werden. Extreme
Größen können zu Leistungseinbußen führen.

Die maximale Tabellengröße von 32 TB benötigt keine
Large-File-Unterstützung im Betriebssystem. Große Tabellen werden in
Dateien mit einer Größe von je 1 GB aufgeteilt, wodurch etwaige
dateisystem-bedingte Beschränkungen nicht relevant sind.

Die maximale Tabellengröße und die maximale Anzahl von Spalten können
vervierfacht werden, indem man die Default-Blockgröße auf 32 KB
heraufsetzt. Die Tabellengröße kann auch durch Tabellenpartitionierung
vergrößert werden.

Eine Einschränkung ist, dass Indexe nur auf Spalten erstellt werden
können, die bis etwa 2.000 Zeichen groß sind. Um auf größere Spalten
eine UNIQUE-Constraint setzen zu können, nutzen Sie einen funktionalen
Index mit dem MD5-Hash-Wert der Spalte. Um innerhalb einer großen, mit
Text belegten Spalte suchen zu können, verwenden Sie einen
Volltext-Index.

=== Wieviel Plattenplatz wird benötigt, um die Daten aus einer typischen Textdatei abzuspeichern? ===

Eine PostgreSQL-Datenbank kann beim Abspeichern einer einfachen
Textdatei bis zu fünfmal mehr Platz gegenüber der eigentlichen Größe
der Datei beanspruchen.

Betrachten wir eine Datei mit 100.000 Zeilen mit einem Integer und
einer Textbeschreibung pro Zeile. Gehen wir davon aus, dass die
durchschnittliche Länge der Textbeschreibung 20 Byte beträgt. Die
einfache Datei würde 2,8 MB groß sein. Die Größe der
PostgreSQL-Datenbankdatei, die diese Daten enthält, liegt ungefähr bei
5,2 MB:
24 Bytes: jeder Zeilenkopf (ungefähr)
+24 Bytes: ein Integer-Feld und ein Textfeld
+ 4 Bytes: Zeiger auf der Datenseite auf den Tupel
-----------------------------------------------
52 Bytes pro Zeile

Die Größe einer Datenseite in PostgreSQL beträgt 8192 Bytes (8 KB),
also:
8192 Bytes pro Seite
--------------------- = 146 Zeilen pro Seite (abgerundet)
52 Bytes pro Zeile

100.000 Datenzeilen
------------------------ = 685 Datenbankseiten (aufgerundet)
158 Zeilen pro Seite

633 Datenbankseiten * 8192 Bytes pro Seite = 5,185,536 bytes (5,2 MB)

Indexe beanspruchen nicht so viel Platz. Da sie jedoch die Daten
beinhalten, die sie indizieren, können auch sie sehr groß werden.

NULL-Werte werden als Bitmaps gespeichert, wodurch sie sehr wenig
Platz in Anspruch nehmen.

=== Meine Abfragen sind langsam oder benutzen die Indexe nicht. Warum? ===

Indexe werden nicht automatisch bei jeder Abfrage verwendet. Indexe
werden nur dann verwendet, wenn die abzufragende Tabelle eine
bestimmte Größe übersteigt, und die Abfrage nur eine kleine
Prozentzahl der Tabellenzeilen abfragt. Der Grund hierfür ist der,
dass die durch einen Index verursachten Festplattenzugriffe manchmal
länger dauern würden als ein einfaches Auslesen aller Tabellenzeilen
(sequentieller Scan).

Um festzustellen, ob ein Index verwendet werden soll, braucht
PostgreSQL Statistiken über die Tabelle. Diese Statistiken werden
durch die Anweisungen VACUUM ANALYZE bzw. ANALYZE berechnet. Anhand
der Statistiken kennt der Abfragenoptimierer die Anzahl der
Tabellenzeilen und kann besser entscheiden, ob Indexe verwendet werden
sollen. Statistiken sind auch bei der Ermittlung der optimalen
JOIN-Reihenfolgen und -Methoden wertvoll. Daher sollten diese
regelmässig durchgeführt werden, da sich der Inhalt einer Tabelle ja
auch verändert.

Indexe werden normalerweise nicht in ORDER BY-Abfrage oder in JOINs
verwendet. Ein sequentieller Scan mit anschließendem explizitem
Sortiervorgang ist normalerweise schneller als ein Index-Scan einer
großen Tabelle. Jedoch wird bei einer Abfrage, in der LIMIT zusammen
mit ORDER BY verwendet wird, oftmals ein Index verwendet, da nur ein
kleiner Abschnitt der Tabelle zurückgeliefert wird.

Sollte es danach aussehen, also ob der Optimierer irrtümlich einen
sequentiellen Scan ausführt, führen Sie SET enable_seqscan TO 'off'
aus und prüfen Sie, ob die Indexabfrage dadurch scheller geworden ist.

Bei der Nutzung von Wildcard-Operatoren wie LIKE oder ~, können Indexe
nur unter bestimmten Umständen verwendet werden:

* Das Suchmuster muss sich an Anfang des Strings befinden, d.h.:
** LIKE-Suchmuster dürfen nicht mit % anfangen;
** ~ (reguläre Ausdrücke) müssen mit ^ anfangen.
* Das Suchmuster darf nicht mit einer Zeichenklasse (z.B. [a-e]) beginnen.
* Suchmuster, die Gross- und Kleinschreibung nicht berücksichtigen (z.B. ILIKE bzw. ~*), verwenden keine Indexe. Stattdessen können funktionale Indexe verwendet werden, die im Punkt 4.8 beschrieben werden.
* Die Standard-Locale "C" muss während der Datenbank-Initialisierung mit initdb verwendet worden sein, da andere locales den nächstgrößten Wert nicht ermitteln können. Es ist allerdings möglich, einen besonderen text_pattern_ops-Index für solche Fälle zu erstellen.

In Versionen vor 8.0 werden Indexe oft nicht benutzt, wenn die
jeweiligen Datentypen nicht genau übereinstimmen. Dies gilt besonders
für Indexe auf Spalten mit den Datentypen INT2, INT8 und NUMERIC

=== Auf welche Weise kann ich sehen, wie der Abfrage-Optimierer meine Abfrage auswertet? ===

Eine ausführliche Erklärung zu diesem Thema findet sich in der [http://www.postgresql.org/docs/current/static/sql-explain.html EXPLAIN] Dokumentation.

=== Wie änder ich das Sortierverhalten von textähnlichen Daten? ===
PostgreSQL sortiert Daten anhand dem bei initdb gesetzten Locale. (Ab 8.4 wird es es möglich sein pro Datenbank ein eigenes Locale zu definieren)

Entspricht das Sortierverhalten nicht dem gewünschten muss man die Locale ändern. Die meisten Locales, außer "C", sortieren anhand der Reihenfolge des entsprechenden Wörterbuches. Das Locale "C" ignoriert jegliche Punktuation und Zwischenraum.

=== Wie verfahre ich bei der Suche mit regulären Ausdrücken und bei einer Suche, bei der Groß- und Kleinschreibweisen ignoriert werden? Wie verwende ich einen Index bei solchen Suchabfragen? ===

Der Operator ~ wendet einen regulären Ausdruck an und ~* wendet ihn
an, ohne die Groß- und Kleinschreibung zu beachten. Ebenso beachtet
LIKE die Groß- und Kleinschreibung, und ILIKE nicht.

Gleichheitsvergleiche, die Groß- und Kleinschreibung ignorieren,
werden in der Regel so ausgedruckt:
SELECT *
FROM tabelle
WHERE LOWER(spalte) = 'abc'

Hier wird kein normaler Index benutzt. Legt man hingegen einen
funktionalen Index an, so wird er auf jeden Fall verwendet:
CREATE INDEX tabelle_index ON tabelle (LOWER(spalte))

Falls der obige Index als einen UNIQUE-Index angelegt wird, können
keine Werte in die Spalte eingefügt werden, die sich nur durch ihre
Groß- und Kleinschreibung unterscheiden. Um Fehler zu vermeiden muß
ein CHECK-Constraint oder ein Trigger eingesetzt werden.

=== Wie ermittle ich in einer Abfrage, ob ein Feld NULL ist? Kann nach der NULL-Belegung sortiert werden? ===

Testen Sie die Spalte mit IS NULL bzw. IS NOT NULL.
SELECT
*
FROM
tabelle
WHERE
spalte IS NULL

Beim konkatenieren mit einen NULL-Wert wir das Ergebnis auch NULL. Um dies zu verhindern verwenden Sie am besten [http://www.postgresql.org/docs/current/static/functions-conditional.html COALESCE()]
SELECT
COALESCE(col1, '') || COALESCE(col2, '')
FROM tab;

Um die Spalte danach zu sortieren, ob sie mit NULL belegt ist oder nicht, verwenden Sie die Bedingungen IS NULL bzw. IS NOT NULL in der ORDER BY-Klausel. Da Bedingungen, die wahr sind, höher als das Gegenteil sortiert werden, bewirkt die folgende Abfrage, dass die NULL-Spalten zuerst gelistet werden:
SELECT
*
FROM
tabelle
ORDER BY
(spalte IS NOT NULL)

Ab PostreSQL 8.3 und höher, ist es möglich das standardisierte NULLS FIRST/NULLS LAST zu verwenden um die Position der NULL-Werte im Ergebnis zu bestimmen. (bei FIRST stehen diese zu erst, bei LAST am Ende)
SELECT
*
FROM
tab
ORDER BY
col NULLS FIRST;

=== Was ist der Unterschied zwischen den verschiedenen CHAR-Typen? ===
{| border="1"
!Typ
!interner Name
!Bemerkungen
|-
|VARCHAR(n)
|varchar
|die Größe legt die Maximallänge fest; kein Auffüllen mit Leerzeichen
|-
|CHAR(n)
|bpchar
|mit Leerzeichen gefüllt bis zur angegebenen Länge
|-
|TEXT
|text
|keine obere Grenze für die Länge
|-
|BYTEA
|bytea
|Bytearray mit variabler Länge (auch für '\0'-Bytes geeignet)
|-
|"char" (with the quotes)
|char
|ein Zeichen
|}

Der interne Name kommt vor allem in den Systemkatalogen und in manchen
Fehlermeldungen vor.

Die ersten vier Typen sind "varlena"-Typen (d.h. die ersten vier Bytes
geben die Länge an, gefolgt von den Daten). Daher ist der tatsächlich
belegte Platz immer etwas mehr als die deklarierte Feldgröße.
Allerdings wird unter Umständen auf diese Datentypen Datenkompression
durch das TOAST- Verfahren angewendet, womit der tatsächlich belegte
Platz auch geringer als erwartet ausfallen kann.

Für die Speicherung von Zeichenketten variabler Länge empfiehlt sich
VARCHAR(n). Die maximale Länge eines VARCHAR(n)-Felds wird bei der
Tabellendefinition festgelegt. TEXT setzt keine Längengrenze,
allerdings gibt es eine systembedingte Obergrenze von 1 GB.

CHAR(n) ist geeignet für die Speicherung von Zeichenketten, die alle
die gleiche Länge haben. Bitte beachten Sie, dass CHAR(n) automatisch
Zeichenketten bis zur definierten Feldlänge mit Leerzeichen ausfüllt,
während bei VARCHAR(n) nur die tatsächlich eingegebene Zeichenkette
gespeichert wird.

BYTEA ist für binäre Daten, besonders für Werte, die NULL-Bytes haben.

Alle der hier erwähnten Typen weisen ähnliche Performanzeigenschaften
auf.

=== Wie erzeuge ich ein serielles Feld mit automatischer Erhöhung des Wert? ===

PostgreSQL bietet einen SERIAL-Datentyp. Dies ist zwar kein richtiger Datentyp. Es ist die Kurzform für das Erstellen einer Spalte vom Typ Integer, die von einer Sequenz befüllt wird.

Zum Beispiel:
CREATE TABLE person (
id SERIAL,
name TEXT
)

wird automatisch in:
CREATE SEQUENCE person_id_seq;
CREATE TABLE person (
id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
name TEXT
);

umgewandelt.

Die automatisch generierte Sequenz besitzt immer folgenden Namen:
''tabellederspalte''-''namederspalte''_seq

Die Man-Page zu CREATE SEQUENCE beinhaltet mehr Informationen zu Sequenzen.

Es gibt auch einen Typ BIGSERIAL, dieser unterscheidet sich aber nur darin dass die Spalte den Typ BIGINTEGER bekommt. BIGSERIAL sollte verwendet werden wenn es zu erwarten ist, dass mehr als 2 Milliarden Sequenz-Werte verwendet werden.

=== Wie bekomme ich den Wert einer SERIAL-Sequenz? ===

Eine Möglichkeit wäre, mit der nextval()-Funktion den nächsten SERIAL-Wert von dem Sequenzobjekt vor der Auszuführung einer INSERT-Anweisung anzufordern und ihn dann explizit in die INSERT-Anweisung einzubinden. Anhand der Beispieltabelle in 4.11.1 könnte dieser Vorgang in einer Pseudosprache so aussehen:

new_id = output of execute("SELECT nextval('person_id_seq')");
execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");

Danach stünde der neue Wert in der Variablen new_id für die Verwendung in weiteren Abfragen zur Verfügung, zum Beispiel als Fremdschlüssel zur Tabelle 'person'). Bitte beachten Sie, dass der Name des automatisch erstellten SEQUENCE-Objektes folgenden Name hat: «table»_«serialcolumn»_seq wobei 'table' und 'serialcolumn' die Namen
der jeweils betreffenden Tabelle / Spalte darstellen.

Als weitere Möglichkeit können Sie nach einer INSERT-Anweisung den automatisch eingefügten SERIAL-Wert mit der currval()-Funktion zurückgeben lassen:

execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
new_id = output of execute("SELECT currval('person_id_seq')");

Die einfachste Möglichkeit ist es RETURNING zu verwenden. Ein einfaches Beispiel sähe so aus:
INSERT INTO person (name) VALUES ('Blaise Pascal') RETURNING id;

=== Führt currval() zu einer Race-Condition mit anderen Nutzern? ===

Nein. currval() liefert einen Wert zurück, der von Ihrer
Datenbank-Session bestimmt wird, und der anderen Sessionen nicht zur
Verfügung steht.

=== Warum werden die Sequenzwerte nach einem Transaktionsabbruch nicht zurückgesetzt? Warum gibt es Lücken in der Nummerierung meiner Sequenz-/SERIAL-Spalte? ===

Um die gleichzeitige Abarbeitung von Transaktionen zu verbessern,
werden Sequenzen gerade nicht für andere Transaktionen gesperrt,
sondern die Sequenznummern werden den laufenden Transaktionen sofort
zugeteilt. Lücken in der Sequenznummerierung werden durch abgebrochene
Transaktionen verursacht.

=== Was ist ein OID? ===

Jede Zeile, die in PostgreSQL erzeugt wird, bekommt eine eindeutige OID, sofern die Tabelle nicht mit der Option WITHOUT OIDS angelegt wurde. OIDs sind automatisch zugewiesene 4-Byte-Integer, die innerhalb der gesamten Datenbank einmalig sind. Allerdings laufen sie bei einem Wert von ungefähr 4 Milliarden über. PostgreSQL verwendet OIDs, um
seine interne Systemtabellen zu verbinden.

Um einmalige Idenfikatoren in Datentabellen zu erstellen, wird allerdings empfohlen, statt OIDs Werte zu verwenden, die von SERIAL-Sequenzen erzeugt werden. SERIAL-Sequenzen sind innerhalb einer Tabelle einmalig und daher weniger anfällig für Überläufe. Außerdem können 8-Byte-Sequenzwerte mit BIGSERIAL (SERIAL8) erzeugt werden.

=== Was ist ein CTID? ===

CTIDs werden benutzt, um bestimmte physikalische Zeilen durch Block und Offset Werte zu identifizieren. CTIDs verändern sich, sobald Zeilen verändert oder zurückgeladen werden. Sie werden in Indexeinträgen benutzt um auf die physikalischen Zeilen zu zeigen.

=== Wieso bekomme ich einen Fehler: "ERROR: Memory exhausted in AllocSetAlloc()"? ===

Wahrscheinlich gibt es keinen virtuellen Speicher mehr in Ihrem System
oder Ihr Kernel hat niedrige Höchstgrenzen für bestimmte Ressourcen.
Probieren Sie vor dem Start von postmaster folgendes:
ulimit -d 262144
limit datasize 256m

Je nach benutzter Shell wird nur einer dieser Befehle erfolgreich
ausgeführt werden. Auf jedem Fall wird die Grenze des Datensegments
für Prozesse erhöht werden und eventuell die erfolgreiche Ausführung
der Abfrage ermöglichen. Falls Sie ein Problem mit dem SQL-Client
haben, weil das Backend zu viele Daten zurückliefert, versuchen Sie
dies vor dem Start des SQL-Clients.

=== Wie kann ich feststellen, welche PostgreSQL-Version bei mir läuft? ===

Geben Sie in psql SELECT VERSION(); ein.

=== Wie kann ich eine Spalte erstellen, deren Default-Wert immer die aktuelle Uhrzeit enthalten soll? ===

Dazu verwenden Sie CURRENT_TIMESTAMP:
CREATE TABLE test (x INT, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

=== Wie führe ich eine OUTER JOIN durch? ===

PostgreSQL unterstützt OUTER JOINs nach dem SQL- Standardsyntax. Hier
zwei Beispiele:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 ON (t1.spalte = t2.spalte)

bzw.:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 USING (spalte)

Diese identischen Abfragen verknüpfen tabelle_1 mit tabelle_2 über die
Spalte 'spalte' und geben außerdem alle unverknüpften Zeilen in
tabelle_1 (diejenigen, die keine Entsprechung in tabelle_2 haben)
zurück. Ein RIGHT JOIN würde hingegen alle unverknüpften Zeilen in
tabelle_2 hinzufügen und ein FULL JOIN würde alle verknüpften Zeilen
sowie jeweils alle unverknüpften Zeilen aus den beiden Tabellen
zurückliefern. Die Angabe von OUTER ist nicht zwingend und kann in
LEFT, RIGHT und FULL-Verknüpfungen weggelassen werden. Normale
Verknüpfungen sind INNER JOINs.

=== Wie kann ich Abfragen über mehrere Datenbanken hinweg ausführen? ===

Es gibt keinen Weg, innerhalb einer Abfrage auf mehr als eine
Datenbank zuzugreifen. Da PostgreSQL datenbank-spezifische
Systemkataloge lädt, ist eine datenbankübergreifende Abfrage nicht
möglich.

contrib/dblink ist eine Erweiterung, die datenbankübergreifende
Abfragen über Funktionsaufrufe ermöglicht.

=== Wie kann ich mehrere Zeilen bzw. Spalten von einer Funktion zurückgeben lassen? ===

Funktionen können mehrere Zeilen und Spalten zurückgeben, vgl.:
http://www.postgresql.org/docs/techdocs.17.

=== Warum bekomme ich eine Fehlermeldung wie "relation with OID ##### does not exist" wenn ich temporäre Tabellen in PL/PgSQL-Funktionen benutze? ===

In PostgreSQL-Versionen vor 8.3 verarbeitet PL/PgSQL Funktionen in
einer Cache. Dies hat eine unangenehme Nebenwirkung, nämlich dass wenn
eine PL/PgSQL-Funktion auf eine temporäre Tabelle zugreift, und diese
Tabelle anschließend gelöscht bzw. neu erstellt wird, die Funktion
fehlschlagen wird, da die gecachten Funktionsinhalte noch auf die alte
temporäre Tabelle zeigen. Die Lösung für diese Probleme besteht darin,
in der PL/PgSQL- Funktion mittels EXECUTE auf temporäre Tabellen
zuzugreifen. Dies bewirkt, dass bei jedem Funktionsruf die betreffende
Abfrage neu geparst wird.

Dieses Problem taucht in PostgreSQL 8.3 und späteren Versionen nicht
mehr auf.

=== Welche Replikationslösungen gibt es? ===

Der Begriff "replikation" umfasst mehrere verschiedene Technologien,
jede mit eigenen Vor- und Nachteilen. [http://www.postgresql.org/docs/8.3/static/high-availability.html Die Dokumentation enthält eine gute Einführung in das Thema Replikation]

Mit "Master/slave"-Replikation werden Änderungen in einer
Hauptdatenbank durchgeführt und an "Sklaven" verteilt, die im
Nur-Lese-Modus arbeiten. Die populärste Lösung für PostgreSQL ist
Slony-I.

"Multi-master replication" ermöglicht sowohl lesende als auch
schreibende Zugriffe über mehrere Datenbank-Server hinweg. Allerdings
hat diese Art von Replikation eine negative Auswirkung auf die
Performanz durch die Notwendigkeit, Änderungen zwischen Servern zu
synchronisieren. Pgcluster ist die populärste freie Lösung für
PostgreSQL.

Es gibt auch einige kommerzielle und hardware-basierte
Replikationslösungen für verschiedene Arten der Replikation.

=== Warum werden die Tabellen- und Spaltennamen in meiner Abfrage nicht erkannt? Warum werden Großbuchstaben umgewandelt? ===

Die häufigste Ursache ist die Verwendung von Gänsefüßchen bei der
Anlegung von Tabellen, z.B.:
CREATE TABLE "Tabelle"
("SPALTE1" INT)

Dadurch werden Tabellen- und Spaltennamen (sog. Identifikatoren) in
genau der Schreibweise gespeichert (vgl. Dokumentation), was dazu
führt, dass man sie danach immer in Gänsefüßchen angeben muss. Im
obigen Beispiel muss man also immer etwa SELECT * FROM "Tabelle"
verwenden. Um dieses Problem zu vermeiden, müssen Sie immer eines der
folgenden Punkte beachten:

* bei der Tabellenanlegung keine Gänsefüßchen verwenden;
* in Identifikatoren nur Kleinschreibung verwenden;
* immer Identifikatoren mit Gänsefüßchen versehen

== Anmerkungen des Übersetzers ==

Die englische Vorlage dieser FAQ wird ständig überarbeitet. Daher
liegt die Übersetzung nicht immer auf dem aktuellsten Stand.

Die aktuellste Version der deutschen Übersetzung befindet sich immer
unter http://sql-info.de/de/postgresql/FAQ_german.html. Diese
"Arbeitsversion" enthält eventuell Änderungen, die noch nicht auf der
PostgreSQL-Website eingebunden worden sind.

Über Verbesserungshinweise und Korrekturvorschläge sowie
Verständnisfragen zum Inhalt der FAQ freue ich mich. Ich nehme auch
allgemeine Fragen zu PostgreSQL gerne entgegen, verweise jedoch auf
die Mailing-Listen als schnelle und zuverlässige Anlaufstellen.

[[Category:FAQ]]

FAQ/de

2011-12-06T18:41:26Z

Mastermind: /* Wie ermittle ich in einer Abfrage, ob ein Feld NULL ist? Kann nach der NULL-Belegung sortiert werden? */

{{Languages}}

== Allgemeine Fragen ==

=== Was ist PostgreSQL? Wie wird es ausgesprochen? ===

Die (englische) Aussprache ist "Post-Gres-Q-L". Im allgemeinen
Sprachgebrauch hat sich die Kurzform "Postgres" auch durchgesetzt.
(Für diejenigen, die es interessiert: eine MP3-Datei mit der
amerikanischen Aussprache befindet sich hier:
http://www.postgresql.org/files/postgresql.mp3

PostgreSQL ist ein objektrelationales Datenbanksystem, das die Vorzüge
von kommerziellen Datenbanksystemen mit zukunftsweisenden Innovationen
kombiniert. PostgreSQL ist freie Software und dessen kompletter
Quellcode ist öffentlich verfügbar.

Die PostgreSQL-Entwicklung wird von einem Team von meist freiwilligen
Entwicklern durchgeführt. Dieses Team ist für die Gesamtentwicklung
von PostgreSQL verantwortlich. Es handelt sich um ein
Gemeinschaftsprojekt, das nicht von einer bestimmten Firma
kontrolliert wird. Lesen Sie die Entwickler-FAQ:
http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn Sie an einer
Mitarbeit interessiert sind.

=== Wer kontrolliert PostgreSQL? ===

Falls Sie nach dem Namen eines etwaigen Inhabers bzw. nach einem
allmächtigen Zentralkommittee suchen - sparen Sie sich die Mühe, sowas
existiert gar nicht. Es gibt zwar das "Core Committee" sowie
Entwickler, die CVS-Schreibberechtigung haben, jedoch haben diese
Gruppen eher nur eine administrative Rolle. Das Projekt wird durch die
Community gesteuert, die aus den Entwicklern sowie natürlich auch den
Nutzern besteht - jeder kann daran teilnehmen. (Lesen Sie die
Entwickler-FAQ: http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn
Sie an der PostgreSQL-Entwicklung teilnehmen möchten).

=== Welchem Copyright unterliegt PostgreSQL? ===

PostgreSQL wird unter der klassischen BSD-Lizenz herausgegeben. Im
Grunde genommen erlaubt diese den Nutzern, beliebig mit dem Code
umzugehen, auch der Weiterverkauf von Binärversionen ohne Quellcode
ist erlaubt. Die einzige Einschränkung besteht darin, dass PostgreSQL
auf keinen Fall für etwaige Probleme mit der Software haftet. Außerdem
muß der Copyright- Text in allen Kopien der Software enthalten sein.
Dies ist der Originaltext der BSD-Lizenz:

PostgreSQL Data Base Management System

Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group
Portions Copyright (c) 1994-6 Regents of the University of California

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose, without fee, and without a written
agreement is hereby granted, provided that the above copyright notice
and this paragraph and the following two paragraphs appear in all
copies.

IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY
FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES,
INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND
ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE
PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF
CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT,
UPDATES, ENHANCEMENTS, OR MODIFICATIONS.

Es gilt die Copyright-Klausel im Original!

=== Auf welchen Plattformen läuft PostgreSQL? ===

Normalerweise kann PostgreSQL auf jeder modernen UNIX-kompatiblen
Plattform eingesetzt werden. Diejenigen Plattformen, die bei der
jeweiligen Versionsfreigabe getestet wurden, sind in den
Installationsanleitungen aufgelistet.

PostgreSQL läuft auch auf Microsoft NT-basierten Betriebssystemen wie
Windows 2000 SP4, XP und Server 2003. Ein vorgefertigtes
Installationspaket kann von http://pgfoundry.org/projects/pginstaller
heruntergeladen werden. DOS-basierte Windows-Versionen (Win95, Win98,
WinMe) können PostgreSQL nur mit Hilfe der Cygwin-Umgebung ausführen.

=== Woher bekomme ich PostgreSQL? ===

Per Web-Browser hier: http://www.postgresql.org/ftp/ und per FTP hier:
ftp://ftp.postgresql.org/pub/.

=== Was ist die neueste Version von PostgreSQL? ===

Die neueste Version von PostgreSQL kann auf der [http://www.postgresql.org/ Website] eingesehen werden.

Die Freigabe einer neuen Hauptversion erfolgt in der Regel jährlich, kleinere Korrekturversionen alle paar Monaten. Die kleineren Updates werden "Minor"-Updates, die großen jährlich erscheinenden "Major"-Updates genannt. "Minor"-Update erscheinen in der Regel gleichzeitig für alle unterstützten "Major"-Versionen. [http://www.postgresql.org/support/versioning Falls Sie dieses Thema interessiert sollten Sie hier weiterlesen.]

=== Wo bekomme ich Support für PostgreSQL? ===

Die PostgreSQL-Community bietet Unterstützung per Mailing-Liste. Die
Web-Seite http://www.postgresql.org/community/lists/ bietet einen
Überblick. Die Listen general und bugs bieten einen guten Einstieg.

Eine deutschsprachige Mailing-Liste gibt es hier:
http://archives.postgresql.org/pgsql-de-allgemein/.

Der wichtigsten IRC-Channel ist #postgresql auf Freenode
(irc.freenode.net). Unter UNIX/Linux können Sie mit z.B. irc -c
'#postgresql' "$USER" irc.freenode.net. daran teilnehmen. Auf Freenode
gibt es folgende Channels:
* #postgresql-es (spanisch)
* #postgresqlfr (französischen)
* #postgresql-br (brasilianischen)

Es gibt außerdem einen PostgreSQL-Channel bei EFNet.

Eine Liste von Unternehmen, die Support für PostgreSQL auf kommerzieller Basis leisten, kann unter http://www.postgresql.org/support/professional_support eingesehen werden.

=== Wie kann ich einen Fehlerbericht abgeben? ===

Nutzen Sie das Formular unter
http://www.postgresql.org/support/submitbug. Schauen Sie aber vorher
unter ftp://ftp.postgresql.org/pub/ nach, ob es mittlerweile eine
neuere PostgreSQL-Version gibt, in der der Fehler behoben wurde.

Bugs, die über das Formular bzw. eine der Mailing-Listen
bekanntgegeben wurden, erhalten typischerweise einer der folgenden
Reaktionen:

* es ist kein Bug, der Grund wird benannt
* es ist ein bereits bekannter Bug, der bereits auf der TODO-Liste aufgenommen wurde
* der Bug wurde in der aktuellen Version behoben
* der Bug wurde bereits behoben, befindet sich aber noch nicht in einer offiziell veröffentlichten Version
* es wird um eingehendere Informationen gebeten, z.B.:
** Betriebssystem
** PostgreSQL-Version
** reproduzierbares Fallbeispiel
** Debugging-Information
** Debugger-Backtrace-Ausgabe
* der Bug ist neu. Folgendes könnte passieren:
** ein Patch wird erstellt und in der nächsten Version eingebaut
** der Bug kann nicht sofort behoben werden und wird auf die TODO-Liste gesetzt

=== Wie erfahre ich von bekannten Bugs oder fehlenden Features? ===

PostgreSQL unterstützt eine erweiterte Teilmenge von SQL:2003. Siehe
unsere TODO-Liste unter http://www.postgresql.org/docs/faqs.TODO.html
für eine Auflistung der bekannten Bugs, fehlenden Features und
zukünftigen Pläne.

Eine Anfrage nach einem neuen Feature führt normalerweise zu einer der
folgenden Antworten:

* das Feature ist bereits auf der TODO-Liste
* das Feature ist nicht wünschenswert, weil:
** es vorhandene Funktionalität dupliziert, welche bereits dem SQL-Standard folgt
** es würde die Komplexität der Code-Basis erhöhen, ohne nennenswerte Vorteile zu bringen
** es wäre unsicher bzw. unzuverlässig
* das neue Feature wird der TODO-Liste hinzugefügt

PostgreSQL verwendet kein Bugtracking-System, da es sich als effizienter erwiesen hat, E-Mails direkt zu beantworten und die TODO-Liste aktuell zu halten. In der Praxis werden Bugs sehr schnell beseitigt, und diejenigen Bugs, die Auswirkungen auf eine große Anzahl von Nutzern haben, werden meist kurzfristig korrigiert. Der einzige Überblick über alle Änderungen, Verbesserungen und Korrekturen in einer PostgreSQL-Version befindet sich in den CVS-Log-Meldungen. Auch die Release-Notes listen nicht jede Änderung in der Software auf.

=== Welche Dokumentation ist für PostgreSQL verfügbar? ===

PostgreSQL bietet umfangreiche Dokumentation, darunter ein großes
Handbuch, man-Pages und einige kleine Testprogramme. Siehe das /doc-
Verzeichnis. Ausserdem sind alle Handbücher online unter
http://www.postgresql.org/docs/ verfügbar.

Zwei Bücher zu PostgreSQL sind online verfügbar unter
http://www.postgresql.org/docs/books/awbook.html und
http://www.commandprompt.com/ppbook/ .

Eine Liste lieferbarer PostgreSQL-Bücher befindet sich unter
http://www.postgresql.org/docs/books Diverse technische Artikel
befinden sich unter http://www.postgresql.org/docs/techdocs .

psql hat einige nützliche \d-Befehle, um Informationen über Typen,
Operatoren, Funktionen, Aggregate, usw. zu zeigen.

Die PostgreSQL-Website enthält noch mehr Dokumentation.

=== Wie kann ich SQL lernen? ===

Die oben erwähnten PostgreSQL-spezifische Bücher bieten einen guten
Einstieg. Viele PostgreSQL-Anwender mögen "The Practical SQL Handbook"
(Bowman et al., Addison Wesley). Andere dagegen mögen "The Complete
Reference SQL" (Groff et al., McGraw-Hill).

Es gibt ausserdem einige nützliche Online-Tutorials:

* http://www.intermedia.net/support/sql/sqltut.shtm
* http://sqlcourse.com
* http://www.w3schools.com/sql/default.asp
* http://mysite.verizon.net/Graeme_Birchall/id1.html

=== Wie kann ich im Entwicklerteam mitarbeiten? ===

Lesen Sie in der Entwickler-FAQ unter
[[Developer_FAQ | Developer FAQ]] nach.

=== Wie läuft PostgreSQL im Vergleich zu anderen Datenbanksystemen? ===

Es gibt verschiedene Methoden, Software zu messen: Eigenschaften,
Performanz, Zuverlässigkeit, Support und Preis.

==== Eigenschaften ====

PostgreSQL besitzt die meisten Eigenschaften - wie
Transaktionen, Unterabfragen (Subqueries), Trigger, Views,
referenzielle Integrität bei Fremdschlüsseln und verfeinertes
Locking - die bei großen kommerziellen DBMS vorhanden sind. Es
bietet außerdem einige anderen Eigenschaften, die diese nicht
immer haben, wie benutzerbestimmte Typen, Vererbung, Regeln,
und die Multi-Versionen-Steuerung zum Verringern
konkurrierender Locks.

==== Performanz ====
Die Performanz von PostgreSQL ist mit der von kommerziellen und
anderen Open-Source-Datenbanken vergleichbar. In manchen
Bereichen ist es schneller, in anderen langsamer. In der Regel
beträgt der Unterschied +/-10%.

==== Zuverlässigkeit ====
Es ist selbstredend, dass ein DBMS wertlos ist, wenn es nicht
zuverlässig arbeitet. Daher bemühen wir uns, nur streng
geprüften und beständigen Code freizugeben, der nur ein Minimum
an Programmfehlern aufweist. Jede Freigabe hat mindestens einen
Monat Betatest-Phase hinter sich, und unsere Freigabehistorie
beweist, dass wir stabile und solide Versionen freigeben, die
im Produktionsbetrieb genutzt werden können. Wir glauben, dass
wir im Vergleich mit anderer Datenbanksoftware vorteilhaft
dastehen.

==== Support ====
Unsere Mailinglisten bieten die Möglichkeit, gemeinsam mit
einer großen Gruppe von Entwicklern und Benutzern mögliche
Probleme zu lösen. Wir können nicht immer eine Fehlerbehebung
garantieren, kommerzielle DBMS tun dies aber auch nicht. Der
direkte Kontakt zur Entwickler- und Benutzergemeinschaft und
der Zugriff auf die Handbücher und den Quellcode ermöglicht
einen im Vergleich zu anderen DBMS höherwertigeren Support. Es
gibt jedoch auch Anbieter von kommerziellen Support-Leistungen
(siehe FAQ-Punkt 1.7).

==== Preis ====
PostgreSQL ist frei verfügbar, sowohl für die kommerzielle wie
auch für die nicht-kommerzielle Nutzung. Sie können den
PostgreSQL-Code ohne Einschränkungen (außer denjenigen, die in
der oben angegebene BSD-artigen Lizenz erwähnt werden) in Ihr
Produkt integrieren.

=== Kann PostgreSQL eingebettet (embedded) werden? ===
PostgreSQL basiert auf einer Server/Client-Architektur, diese benötigt separate Prozesse für jeden Klient und Server, hinzukommen auch noch weitere "Helfer-Prozesse" (z. B. für autovacuum und stats-collector). Zwar können einige "embedded-Architekturen" diese Anforderungen erfüllen, aber wenn der Datenbank-Prozess innerhalb des Applikations-Prozesses laufen muss, kann PostgreSQL nicht verwendet werden. Dazu sollte man leichtere Datenbanken nehmen.

=== Wie kann ich mich von einer Maillingliste abmelden? Wie verhindere ich es, dass ich doppelte E-Mails bekomme? ===
Majordomo ermöglicht es sich von allen Maillinglisten an- und abzumelden, ggf. müssen Sie sich zuerst ihr Majordomo-Passwort zuschicken lassen.
[http://mail.postgresql.org/mj/mj_wwwusr PostgreSQLs Majordomo erreichen Sie hier.]

Die PostgreSQL-Maillinglisten sind so konfiguriert, dass Antworten an den ursprünglichen Autor und an die Maillingliste verschickt werden. Somit soll erreicht werden dass Benutzer immer schnellstmöglichst eine Antwort erhalten können. Diese Einstellungen können Sie auch über die Konfiguration von Majordomo ändern, ändern Sie dafür die Einstellung für ''eliminatecc''. Sie können auch einstellen dass Sie selbst keine Antwort auf Ihre eigenen E-Mails bekommen, ändern sie dafür die Einstellung für ''selfcopy''.
[http://mail.postgresql.org/mj/mj_wwwusr PostgreSQLs Majordomo erreichen Sie hier.]

== Fragen zu Benutzerprogrammen ==

=== Welche Schnittstellen gibt es für PostgreSQL? ===

Die PostgreSQL-Installation stellt nur Schnittstellen für C und
Embedded C bereit. Alle weitere Schnittstellen sind unabhängige
Projekte, die einzeln heruntergeladen werden werden müssen. Diese
Trennung ermöglicht individuelle Entwickler-Teams und
Entwicklungszyklen für die jeweiligen Projekte.

Einige Programmiersprachen wie PHP haben eine PostgreSQL-
Schnittstelle bereits eingebaut. Schnittstellen für Sprachen wie Perl,
TCL, Python und viele anderen sind unter http://gborg.postgresql.org
im Bereich Drivers/Interfaces verfügbar sowie per Internet-Suche.

=== Wie kann man PostgreSQL in einer Website nutzen? ===

Eine nette Einführung zu datenbank-gestützten Webseiten kann unter
http://www.webreview.com (engl.) eingesehen werden.

Für die Web-Integration ist PHP eine ausgezeichnete Schnittstelle. PHP
gibt es bei http://www.php.net

Desweiteren bietet sich die Perl-Schnittstelle mit CGI.pm
oder mod_perl auch an.

=== Hat PostgreSQL eine grafische Benutzerschnittstelle? ===

Es gibt eine große Anzahl von GUI-Programmen für PostgreSQL - sowohl
kommerziell als auch Open-Source. [http://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools Eine englische Liste befindet sich hier.]

== Administrative Fragen ==

=== Wie installiere ich PostgreSQL woanders als in /usr/local/pgsql? ===

Bei der Ausführung von configure die Option --prefix mit dem Zielverzeichnis angeben.

=== Wie regle ich Zugriffe von anderen Rechnern? ===

PostgreSQL ist standardmäßig so eingestellt, dass Verbindungen nur vom
lokalen Rechner über Unix Domain Sockets bzw. TCP/IP möglich sind.
Verbindungen von anderen Rechnern werden erst dann ermöglicht, wenn
Sie in der Datei postgresql.conf die Einstellung listen_addresses
anpassen, in der Datei $PGDATA/pg_hba.conf host-basierte
Authentifizierung einschalten und den Server neu starten.

=== Wie kann ich eine bessere Performanz erreichen? ===

Es gibt drei große Bereiche, in denen Performanzverbesserungen erzielt
werden können:

==== Abfrageoptimierung ====
Die Modifizierung von Abfragen kann eine bessere Performanz erzielen:

* [http://www.postgresql.org/docs/current/interactive/indexes.html Erstellung von Indexen, einschliesslich partieller Indexe sowie Expressionsindexe]
* Einsatz von COPY anstelle multipler INSERT-Anweisungen
* Gruppierung von mehreren Abfragen innerhalb einer Transaktion, um Aufwand beim Abschluss von Transaktionen einzusparen
* Einsatz von CLUSTER beim Holen von einer großen Anzahl von Datenreihen aus einem Index
* Einsatz von LIMIT, um eine Untermenge der Abfragenergebnisse zurückzuliefern
* [http://www.postgresql.org/docs/current/interactive/sql-prepare.html Einsatz von vorbereiteten Befehlen (prepared queries)]
* Einsatz von ANALYZE, um die Datenbankstatistik für den Abfragenplaner aktuell zu halten
* [http://www.postgresql.org/docs/current/static/routine-vacuuming.html Regelmäßiger Einsatz von VACUUM bzw. pg_autovacuum (autovacuum ist seit Version 8.3 standardmäßig aktiviert)]
* Bei großen Datenveränderungen die Löschung von Indexen

==== Server-Konfiguration ====
Einige Einstellungen in der Datei postgresql.conf wirken sich auf die Performanz aus. Das Handbuch enthält unter http://www.postgresql.org/docs/current/static/runtime-config.html eine komplette Auflistung.

Kommentare zu den jeweiligen Einstellungen gibt es unter http://www.varlena.com/varlena/GeneralBits/Tidbitsannotated_conf_e.html und http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html.

==== Hardware-Auswahl ====
Die Auswirkung von Hardware auf Performanz wird unter http://momjian.us/main/writings/pgsql/hw_performance/index.html und http://www.powerpostgresql.com/PerfList/ erläutert.

=== Welche Debugging-Funktionen sind für PostgreSQL verfügbar? ===

Unter den Optionen für die Server-Konfigurierung gibt es zahlreiche
log_*-Variablen, die die Ausgabe von Abfrage- und Prozessstatistiken
ermöglichen. Diese können für Debugging-Zwecke sowie Performanz-Tests
sehr nützlich sein.

=== Ich bekomme die Meldung "Sorry, too many clients", wenn ich eine Verbindung aufzubauen versuche. Warum? ===

Ihr System hat die maximal zulässige Anzahl von Datenbankverbindungen
erreicht (Voreinstellung 100). Sie müssen die maximale Anzahl der
gleichzeitig ausführbaren Backend-Prozesse hochsetzen, indem Sie in
postgresql.conf den Wert max_connections ändern und den Server
neustarten.

=== Wie wird PostgreSQL aktualisiert? ===

Allgemeine Informationen zur Aktualisierung von PostgreSQL gibt es auf
der Seite http://www.postgresql.org/support/versioning. Detaillierte
technische Informationen gibt es auf der Seite
http://www.postgresql.org/docs/current/static/install-upgrading.html

=== Kommt PostgreSQL mit den Anpassungen der Sommerzeit in verschiedenen Ländern klar? ===

Für die Berücksichtigung der Sommerzeit verwendet PostgreSQL Seit dem Release 8.0 die weiterverbreitete tzdata-Datenbank (auch bekannt als "zoneinfo database" oder "[http://www.twinsun.com/tz/tz-link.htm Olzen timezone database]".

Jedes Update von PostgreSQL beinhaltet die aktuellen tzdata Dateien, daher sollte es reichen die Minor-Updates der eingesetzten Major Version im Auge zu behalten.

Unter der Vorraussetzung dass das Betriebssystem diese Dateien schon in einer stets aktuellen Version vorbehält, ist es üblich, dass man diese Dateien verwendet. PostgreSQL bietet dazu eine compile-option an.

=== Welche Hardware eignet sich für den Betrieb mit PostgreSQL? ===

PostgreSQL läuft auf fast jeder Hardware-Kombination. Im PC-Bereich
gibt es allerdings sehr große Abweichungen in der Qualität. Für einen
Arbeitsplatz- oder Entwicklungsrechner mag dies nicht so bedeutend
sein, im Server-Betrieb jedoch lohnt sich auf jeden Fall die
Investition in teurere Bestandteile (Stichwörter ECC-Speicher, SCSI,
Hauptplatinen und Netzteile von namhaften Herstellern). Nutzen Sie
unsere Mailing-Listen, um Hardware-Optionen zu diskutieren.

== Fragen zum Betrieb ==

=== Wie wähle ich per SELECT-Anweisung nur die ersten paar Zeilen bzw. eine beliebige Zeile in einer Abfrage aus? ===

Wenn Sie bei der Ausführung der Abfrage die Anzahl der anzufordenden
Reihen bereits kennen, nutzen Sie LIMIT. Wenn die ORDER BY- Anweisung
mit einem Index verwendet wird, ist es möglich, dass die gesamte
Abfrage nicht ausgeführt werden muss. Wenn Sie die Anzahl der der
anzufordenden Reihen nicht kennen, verwenden Sie einen Cursor und
FETCH.

Um eine beliebige Zeile auszuwählen, nutzen Sie ORDER BY random():
SELECT spalte
FROM tabelle
ORDER BY random()
LIMIT 1

=== Wie finde ich heraus, welche Tabellen, Indexe, Datenbanken oder Benutzer in der Datenbank definiert sind? Wie bekomme ich die von psql verwendeten Abfragen? ===

In psql zeigt der Befehl \dt eine Liste der Datenbanktabellen. Weitere
psql-Befehle lassen sich mit \? anzeigen. Sie können sich die Datei
pgsql/src/bin/psql/describe.c mit dem Quellcode für psql ansehen. Sie
enthält die SQL-Abfragen, die die Backslash-Kommandos (\) ausführen.
Sie können psql auch mit der -E Option starten. Danach gibt psql die
Abfragen aus, die es bei der Ausführung der Befehle benutzt. Außerdem
biete PostgreSQL ein SQL-kompatibles INFORMATION SCHEMA, das
Metainformation über die Datenbank zur Verfügung stellt.

Mit psql -l können Sie alle Datenbanken anzeigen lassen.

Die Datei pgsql/src/tutorial/syscat.source enthält außerdem viele
SELECT- Abfragen, mit deren Hilfe man Information über die
Systemtabellen erhalten kann.

=== Wie ändere ich den Datentyp einer Spalte? ===

Ab Version 8.0 kann der Datentyp einer Spalte mit ALTER TABLE ALTER
COLUMN TYPE geändert werden, sofern der neue Datentyp die Werte des
alten Datentype aufnehmen kann.

Bei früheren Versionen gehen Sie wie folgt vor:
BEGIN;
ALTER TABLE tabelle ADD COLUMN neue_spalte neuer_datentyp;
UPDATE tabelle SET neue_spalte = CAST(alte_spalte AS neuer_datentyp);
ALTER TABLE tabelle DROP COLUMN alte_spalte;
COMMIT;

Um den Speicherplatz freizugeben, der von der gelöschten Spalte
verwendet wurde, führen Sie VACUUM FULL aus.

=== Was ist die Maximalgröße für eine Zeile, eine Tabelle, eine Datenbank? ===

Es bestehen folgende Obergrenzen:
Maximale Größe eine Datenbank? unbeschränkt (es existieren
Datenbanken mit 32 TB)
Maximale Größe einer Tabelle? 32 TB
Maximale Größe einer Zeile? 400 GB
Maximale Größe einer Spalte? 1 GB
Maximale Anzahl von Zeilen in einer Tabelle?
unbeschränkt
Maximale Anzahl von Spalten in einer Tabelle?
250-1600 je nach Spaltentyp
Maximale Anzahl von Indexen für eine Tabelle?
unbeschränkt

Selbstverständlich sind dies theoretische Werte, die oft durch die
verfügbaren Platten- und Speicherressourcen beschränkt werden. Extreme
Größen können zu Leistungseinbußen führen.

Die maximale Tabellengröße von 32 TB benötigt keine
Large-File-Unterstützung im Betriebssystem. Große Tabellen werden in
Dateien mit einer Größe von je 1 GB aufgeteilt, wodurch etwaige
dateisystem-bedingte Beschränkungen nicht relevant sind.

Die maximale Tabellengröße und die maximale Anzahl von Spalten können
vervierfacht werden, indem man die Default-Blockgröße auf 32 KB
heraufsetzt. Die Tabellengröße kann auch durch Tabellenpartitionierung
vergrößert werden.

Eine Einschränkung ist, dass Indexe nur auf Spalten erstellt werden
können, die bis etwa 2.000 Zeichen groß sind. Um auf größere Spalten
eine UNIQUE-Constraint setzen zu können, nutzen Sie einen funktionalen
Index mit dem MD5-Hash-Wert der Spalte. Um innerhalb einer großen, mit
Text belegten Spalte suchen zu können, verwenden Sie einen
Volltext-Index.

=== Wieviel Plattenplatz wird benötigt, um die Daten aus einer typischen Textdatei abzuspeichern? ===

Eine PostgreSQL-Datenbank kann beim Abspeichern einer einfachen
Textdatei bis zu fünfmal mehr Platz gegenüber der eigentlichen Größe
der Datei beanspruchen.

Betrachten wir eine Datei mit 100.000 Zeilen mit einem Integer und
einer Textbeschreibung pro Zeile. Gehen wir davon aus, dass die
durchschnittliche Länge der Textbeschreibung 20 Byte beträgt. Die
einfache Datei würde 2,8 MB groß sein. Die Größe der
PostgreSQL-Datenbankdatei, die diese Daten enthält, liegt ungefähr bei
5,2 MB:
24 Bytes: jeder Zeilenkopf (ungefähr)
+24 Bytes: ein Integer-Feld und ein Textfeld
+ 4 Bytes: Zeiger auf der Datenseite auf den Tupel
-----------------------------------------------
52 Bytes pro Zeile

Die Größe einer Datenseite in PostgreSQL beträgt 8192 Bytes (8 KB),
also:
8192 Bytes pro Seite
--------------------- = 146 Zeilen pro Seite (abgerundet)
52 Bytes pro Zeile

100.000 Datenzeilen
------------------------ = 685 Datenbankseiten (aufgerundet)
158 Zeilen pro Seite

633 Datenbankseiten * 8192 Bytes pro Seite = 5,185,536 bytes (5,2 MB)

Indexe beanspruchen nicht so viel Platz. Da sie jedoch die Daten
beinhalten, die sie indizieren, können auch sie sehr groß werden.

NULL-Werte werden als Bitmaps gespeichert, wodurch sie sehr wenig
Platz in Anspruch nehmen.

=== Meine Abfragen sind langsam oder benutzen die Indexe nicht. Warum? ===

Indexe werden nicht automatisch bei jeder Abfrage verwendet. Indexe
werden nur dann verwendet, wenn die abzufragende Tabelle eine
bestimmte Größe übersteigt, und die Abfrage nur eine kleine
Prozentzahl der Tabellenzeilen abfragt. Der Grund hierfür ist der,
dass die durch einen Index verursachten Festplattenzugriffe manchmal
länger dauern würden als ein einfaches Auslesen aller Tabellenzeilen
(sequentieller Scan).

Um festzustellen, ob ein Index verwendet werden soll, braucht
PostgreSQL Statistiken über die Tabelle. Diese Statistiken werden
durch die Anweisungen VACUUM ANALYZE bzw. ANALYZE berechnet. Anhand
der Statistiken kennt der Abfragenoptimierer die Anzahl der
Tabellenzeilen und kann besser entscheiden, ob Indexe verwendet werden
sollen. Statistiken sind auch bei der Ermittlung der optimalen
JOIN-Reihenfolgen und -Methoden wertvoll. Daher sollten diese
regelmässig durchgeführt werden, da sich der Inhalt einer Tabelle ja
auch verändert.

Indexe werden normalerweise nicht in ORDER BY-Abfrage oder in JOINs
verwendet. Ein sequentieller Scan mit anschließendem explizitem
Sortiervorgang ist normalerweise schneller als ein Index-Scan einer
großen Tabelle. Jedoch wird bei einer Abfrage, in der LIMIT zusammen
mit ORDER BY verwendet wird, oftmals ein Index verwendet, da nur ein
kleiner Abschnitt der Tabelle zurückgeliefert wird.

Sollte es danach aussehen, also ob der Optimierer irrtümlich einen
sequentiellen Scan ausführt, führen Sie SET enable_seqscan TO 'off'
aus und prüfen Sie, ob die Indexabfrage dadurch scheller geworden ist.

Bei der Nutzung von Wildcard-Operatoren wie LIKE oder ~, können Indexe
nur unter bestimmten Umständen verwendet werden:

* Das Suchmuster muss sich an Anfang des Strings befinden, d.h.:
** LIKE-Suchmuster dürfen nicht mit % anfangen;
** ~ (reguläre Ausdrücke) müssen mit ^ anfangen.
* Das Suchmuster darf nicht mit einer Zeichenklasse (z.B. [a-e]) beginnen.
* Suchmuster, die Gross- und Kleinschreibung nicht berücksichtigen (z.B. ILIKE bzw. ~*), verwenden keine Indexe. Stattdessen können funktionale Indexe verwendet werden, die im Punkt 4.8 beschrieben werden.
* Die Standard-Locale "C" muss während der Datenbank-Initialisierung mit initdb verwendet worden sein, da andere locales den nächstgrößten Wert nicht ermitteln können. Es ist allerdings möglich, einen besonderen text_pattern_ops-Index für solche Fälle zu erstellen.

In Versionen vor 8.0 werden Indexe oft nicht benutzt, wenn die
jeweiligen Datentypen nicht genau übereinstimmen. Dies gilt besonders
für Indexe auf Spalten mit den Datentypen INT2, INT8 und NUMERIC

=== Auf welche Weise kann ich sehen, wie der Abfrage-Optimierer meine Abfrage auswertet? ===

Eine ausführliche Erklärung zu diesem Thema findet sich in der [http://www.postgresql.org/docs/current/static/sql-explain.html EXPLAIN] Dokumentation.

=== Wie änder ich das Sortierverhalten von textähnlichen Daten? ===
PostgreSQL sortiert Daten anhand dem bei initdb gesetzten Locale. (Ab 8.4 wird es es möglich sein pro Datenbank ein eigenes Locale zu definieren)

Entspricht das Sortierverhalten nicht dem gewünschten muss man die Locale ändern. Die meisten Locales, außer "C", sortieren anhand der Reihenfolge des entsprechenden Wörterbuches. Das Locale "C" ignoriert jegliche Punktuation und Zwischenraum.

=== Wie verfahre ich bei der Suche mit regulären Ausdrücken und bei einer Suche, bei der Groß- und Kleinschreibweisen ignoriert werden? Wie verwende ich einen Index bei solchen Suchabfragen? ===

Der Operator ~ wendet einen regulären Ausdruck an und ~* wendet ihn
an, ohne die Groß- und Kleinschreibung zu beachten. Ebenso beachtet
LIKE die Groß- und Kleinschreibung, und ILIKE nicht.

Gleichheitsvergleiche, die Groß- und Kleinschreibung ignorieren,
werden in der Regel so ausgedruckt:
SELECT *
FROM tabelle
WHERE LOWER(spalte) = 'abc'

Hier wird kein normaler Index benutzt. Legt man hingegen einen
funktionalen Index an, so wird er auf jeden Fall verwendet:
CREATE INDEX tabelle_index ON tabelle (LOWER(spalte))

Falls der obige Index als einen UNIQUE-Index angelegt wird, können
keine Werte in die Spalte eingefügt werden, die sich nur durch ihre
Groß- und Kleinschreibung unterscheiden. Um Fehler zu vermeiden muß
ein CHECK-Constraint oder ein Trigger eingesetzt werden.

=== Wie ermittle ich in einer Abfrage, ob ein Feld NULL ist? Kann nach der NULL-Belegung sortiert werden? ===

Testen Sie die Spalte mit IS NULL bzw. IS NOT NULL.
SELECT
*
FROM
tabelle
WHERE
spalte IS NULL

Beim konkatenieren mit einen NULL-Wert wir das Ergebnis auch NULL. Um dies zu verhindern verwenden Sie am besten [http://www.postgresql.org/docs/current/static/functions-conditional.html COALESCE()]
SELECT
COALESCE(col1, '') || COALESCE(col2, '')
FROM tab;

Um die Spalte danach zu sortieren, ob sie mit NULL belegt ist oder nicht, verwenden Sie die Bedingungen IS NULL bzw. IS NOT NULL in der ORDER BY-Klausel. Da Bedingungen, die wahr sind, höher als das Gegenteil sortiert werden, bewirkt die folgende Abfrage, dass die NULL-Spalten zuerst gelistet werden:
SELECT
*
FROM
tabelle
ORDER BY
(spalte IS NOT NULL)

Ab PostreSQL 8.3 und höher, ist es möglich das standardisierte NULLS FIRST/NULLS LAST zu verwenden um die Position der NULL-Werte im Ergebnis zu bestimmen. (bei FIRST stehen diese zu erst, bei LAST am Ende)
SELECT
*
FROM
tab
ORDER BY
col NULLS FIRST;

=== Was ist der Unterschied zwischen den verschiedenen CHAR-Typen? ===
{| border="1"
!Typ
!interner Name
!Bemerkungen
|-
|VARCHAR(n)
|varchar
|die Größe legt die Maximallänge fest; kein Auffüllen mit Leerzeichen
|-
|CHAR(n)
|bpchar
|mit Leerzeichen gefüllt bis zur angegebenen Länge
|-
|TEXT
|text
|keine obere Grenze für die Länge
|-
|BYTEA
|bytea
|Bytearray mit variabler Länge (auch für '\0'-Bytes geeignet)
|-
|"char" (with the quotes)
|char
|ein Zeichen
|}

Der interne Name kommt vor allem in den Systemkatalogen und in manchen
Fehlermeldungen vor.

Die ersten vier Typen sind "varlena"-Typen (d.h. die ersten vier Bytes
geben die Länge an, gefolgt von den Daten). Daher ist der tatsächlich
belegte Platz immer etwas mehr als die deklarierte Feldgröße.
Allerdings wird unter Umständen auf diese Datentypen Datenkompression
durch das TOAST- Verfahren angewendet, womit der tatsächlich belegte
Platz auch geringer als erwartet ausfallen kann.

Für die Speicherung von Zeichenketten variabler Länge empfiehlt sich
VARCHAR(n). Die maximale Länge eines VARCHAR(n)-Felds wird bei der
Tabellendefinition festgelegt. TEXT setzt keine Längengrenze,
allerdings gibt es eine systembedingte Obergrenze von 1 GB.

CHAR(n) ist geeignet für die Speicherung von Zeichenketten, die alle
die gleiche Länge haben. Bitte beachten Sie, dass CHAR(n) automatisch
Zeichenketten bis zur definierten Feldlänge mit Leerzeichen ausfüllt,
während bei VARCHAR(n) nur die tatsächlich eingegebene Zeichenkette
gespeichert wird.

BYTEA ist für binäre Daten, besonders für Werte, die NULL-Bytes haben.

Alle der hier erwähnten Typen weisen ähnliche Performanzeigenschaften
auf.

=== Wie erzeuge ich ein serielles Feld mit automatischer Erhöhung des Wert? ===

PostgreSQL bietet einen SERIAL-Datentyp. Dies ist zwar kein richtiger Datentyp. Es ist die Kurzform für das Erstellen einer Spalte vom Typ Integer, die von einer Sequenz befüllt wird.

Zum Beispiel:
CREATE TABLE person (
id SERIAL,
name TEXT
)

wird automatisch in:
CREATE SEQUENCE person_id_seq;
CREATE TABLE person (
id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
name TEXT
);

umgewandelt.

Die automatisch generierte Sequenz besitzt immer folgenden Namen:
''tabellederspalte''-''namederspalte''_seq

Die Man-Page zu CREATE SEQUENCE beinhaltet mehr Informationen zu Sequenzen.

Es gibt auch einen Typ BIGSERIAL, dieser unterscheidet sich aber nur darin dass die Spalte den Typ BIGINTEGER bekommt. BIGSERIAL sollte verwendet werden wenn es zu erwarten ist, dass mehr als 2 Milliarden Sequenz-Werte verwendet werden.

=== Wie bekomme ich den Wert einer SERIAL-Sequenz? ===

Eine Möglichkeit wäre, mit der nextval()-Funktion den nächsten SERIAL-Wert von dem Sequenzobjekt vor der Auszuführung einer INSERT-Anweisung anzufordern und ihn dann explizit in die INSERT-Anweisung einzubinden. Anhand der Beispieltabelle in 4.11.1 könnte dieser Vorgang in einer Pseudosprache so aussehen:

new_id = output of execute("SELECT nextval('person_id_seq')");
execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");

Danach stünde der neue Wert in der Variablen new_id für die Verwendung in weiteren Abfragen zur Verfügung, zum Beispiel als Fremdschlüssel zur Tabelle 'person'). Bitte beachten Sie, dass der Name des automatisch erstellten SEQUENCE-Objektes folgenden Name hat: «table»_«serialcolumn»_seq wobei 'table' und 'serialcolumn' die Namen
der jeweils betreffenden Tabelle / Spalte darstellen.

Als weitere Möglichkeit können Sie nach einer INSERT-Anweisung den automatisch eingefügten SERIAL-Wert mit der currval()-Funktion zurückgeben lassen:

execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
new_id = output of execute("SELECT currval('person_id_seq')");

Die einfachste Möglichkeit ist es RETURNING zu verwenden. Ein einfaches Beispiel sähe so aus:
INSERT INTO person (name) VALUES ('Blaise Pascal') RETURNING id;

=== Führt currval() zu einer Race-Condition mit anderen Nutzern? ===

Nein. currval() liefert einen Wert zurück, der von Ihrer
Datenbank-Session bestimmt wird, und der anderen Sessionen nicht zur
Verfügung steht.

=== Warum werden die Sequenzwerte nach einem Transaktionsabbruch nicht zurückgesetzt? Warum gibt es Lücken in der Nummerierung meiner Sequenz-/SERIAL-Spalte? ===

Um die gleichzeitige Abarbeitung von Transaktionen zu verbessern,
werden Sequenzen gerade nicht für andere Transaktionen gesperrt,
sondern die Sequenznummern werden den laufenden Transaktionen sofort
zugeteilt. Lücken in der Sequenznummerierung werden durch abgebrochene
Transaktionen verursacht.

=== Was ist ein OID? ===

Jede Zeile, die in PostgreSQL erzeugt wird, bekommt eine eindeutige OID, sofern die Tabelle nicht mit der Option WITHOUT OIDS angelegt wurde. OIDs sind automatisch zugewiesene 4-Byte-Integer, die innerhalb der gesamten Datenbank einmalig sind. Allerdings laufen sie bei einem Wert von ungefähr 4 Milliarden über. PostgreSQL verwendet OIDs, um
seine interne Systemtabellen zu verbinden.

Um einmalige Idenfikatoren in Datentabellen zu erstellen, wird allerdings empfohlen, statt OIDs Werte zu verwenden, die von SERIAL-Sequenzen erzeugt werden. SERIAL-Sequenzen sind innerhalb einer Tabelle einmalig und daher weniger anfällig für Überläufe. Außerdem können 8-Byte-Sequenzwerte mit BIGSERIAL (SERIAL8) erzeugt werden.

=== Was ist ein CTID? ===

CTIDs werden benutzt, um bestimmte physikalische Zeilen durch Block und Offset Werte zu identifizieren. CTIDs verändern sich, sobald Zeilen verändert oder zurückgeladen werden. Sie werden in Indexeinträgen benutzt um auf die physikalischen Zeilen zu zeigen.

=== Wieso bekomme ich einen Fehler: "ERROR: Memory exhausted in AllocSetAlloc()"? ===

Wahrscheinlich gibt es keinen virtuellen Speicher mehr in Ihrem System
oder Ihr Kernel hat niedrige Höchstgrenzen für bestimmte Ressourcen.
Probieren Sie vor dem Start von postmaster folgendes:
ulimit -d 262144
limit datasize 256m

Je nach benutzter Shell wird nur einer dieser Befehle erfolgreich
ausgeführt werden. Auf jedem Fall wird die Grenze des Datensegments
für Prozesse erhöht werden und eventuell die erfolgreiche Ausführung
der Abfrage ermöglichen. Falls Sie ein Problem mit dem SQL-Client
haben, weil das Backend zu viele Daten zurückliefert, versuchen Sie
dies vor dem Start des SQL-Clients.

=== Wie kann ich feststellen, welche PostgreSQL-Version bei mir läuft? ===

Geben Sie in psql SELECT VERSION(); ein.

=== Wie kann ich eine Spalte erstellen, deren Default-Wert immer die aktuelle Uhrzeit enthalten soll? ===

Dazu verwenden Sie CURRENT_TIMESTAMP:
CREATE TABLE test (x INT, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

=== Wie führe ich eine OUTER JOIN durch? ===

PostgreSQL unterstützt OUTER JOINs nach dem SQL- Standardsyntax. Hier
zwei Beispiele:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 ON (t1.spalte = t2.spalte)

bzw.:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 USING (spalte)

Diese identischen Abfragen verknüpfen tabelle_1 mit tabelle_2 über die
Spalte 'spalte' und geben außerdem alle unverknüpften Zeilen in
tabelle_1 (diejenigen, die keine Entsprechung in tabelle_2 haben)
zurück. Ein RIGHT JOIN würde hingegen alle unverknüpften Zeilen in
tabelle_2 hinzufügen und ein FULL JOIN würde alle verknüpften Zeilen
sowie jeweils alle unverknüpften Zeilen aus den beiden Tabellen
zurückliefern. Die Angabe von OUTER ist nicht zwingend und kann in
LEFT, RIGHT und FULL-Verknüpfungen weggelassen werden. Normale
Verknüpfungen sind INNER JOINs.

=== Wie kann ich Abfragen über mehrere Datenbanken hinweg ausführen? ===

Es gibt keinen Weg, innerhalb einer Abfrage auf mehr als eine
Datenbank zuzugreifen. Da PostgreSQL datenbank-spezifische
Systemkataloge lädt, ist eine datenbankübergreifende Abfrage nicht
möglich.

contrib/dblink ist eine Erweiterung, die datenbankübergreifende
Abfragen über Funktionsaufrufe ermöglicht.

=== Wie kann ich mehrere Zeilen bzw. Spalten von einer Funktion zurückgeben lassen? ===

Funktionen können mehrere Zeilen und Spalten zurückgeben, vgl.:
http://www.postgresql.org/docs/techdocs.17.

=== Warum bekomme ich eine Fehlermeldung wie "relation with OID ##### does not exist" wenn ich temporäre Tabellen in PL/PgSQL-Funktionen benutze? ===

In PostgreSQL-Versionen vor 8.3 verarbeitet PL/PgSQL Funktionen in
einer Cache. Dies hat eine unangenehme Nebenwirkung, nämlich dass wenn
eine PL/PgSQL-Funktion auf eine temporäre Tabelle zugreift, und diese
Tabelle anschließend gelöscht bzw. neu erstellt wird, die Funktion
fehlschlagen wird, da die gecachten Funktionsinhalte noch auf die alte
temporäre Tabelle zeigen. Die Lösung für diese Probleme besteht darin,
in der PL/PgSQL- Funktion mittels EXECUTE auf temporäre Tabellen
zuzugreifen. Dies bewirkt, dass bei jedem Funktionsruf die betreffende
Abfrage neu geparst wird.

Dieses Problem taucht in PostgreSQL 8.3 und späteren Versionen nicht
mehr auf.

=== Welche Replikationslösungen gibt es? ===

Der Begriff "replikation" umfasst mehrere verschiedene Technologien,
jede mit eigenen Vor- und Nachteilen. [http://www.postgresql.org/docs/8.3/static/high-availability.html| Die Dokumentation enthält eine gute Einführung in das Thema Replikation]

Mit "Master/slave"-Replikation werden Änderungen in einer
Hauptdatenbank durchgeführt und an "Sklaven" verteilt, die im
Nur-Lese-Modus arbeiten. Die populärste Lösung für PostgreSQL ist
Slony-I.

"Multi-master replication" ermöglicht sowohl lesende als auch
schreibende Zugriffe über mehrere Datenbank-Server hinweg. Allerdings
hat diese Art von Replikation eine negative Auswirkung auf die
Performanz durch die Notwendigkeit, Änderungen zwischen Servern zu
synchronisieren. Pgcluster ist die populärste freie Lösung für
PostgreSQL.

Es gibt auch einige kommerzielle und hardware-basierte
Replikationslösungen für verschiedene Arten der Replikation.

=== Warum werden die Tabellen- und Spaltennamen in meiner Abfrage nicht erkannt? Warum werden Großbuchstaben umgewandelt? ===

Die häufigste Ursache ist die Verwendung von Gänsefüßchen bei der
Anlegung von Tabellen, z.B.:
CREATE TABLE "Tabelle"
("SPALTE1" INT)

Dadurch werden Tabellen- und Spaltennamen (sog. Identifikatoren) in
genau der Schreibweise gespeichert (vgl. Dokumentation), was dazu
führt, dass man sie danach immer in Gänsefüßchen angeben muss. Im
obigen Beispiel muss man also immer etwa SELECT * FROM "Tabelle"
verwenden. Um dieses Problem zu vermeiden, müssen Sie immer eines der
folgenden Punkte beachten:

* bei der Tabellenanlegung keine Gänsefüßchen verwenden;
* in Identifikatoren nur Kleinschreibung verwenden;
* immer Identifikatoren mit Gänsefüßchen versehen

== Anmerkungen des Übersetzers ==

Die englische Vorlage dieser FAQ wird ständig überarbeitet. Daher
liegt die Übersetzung nicht immer auf dem aktuellsten Stand.

Die aktuellste Version der deutschen Übersetzung befindet sich immer
unter http://sql-info.de/de/postgresql/FAQ_german.html. Diese
"Arbeitsversion" enthält eventuell Änderungen, die noch nicht auf der
PostgreSQL-Website eingebunden worden sind.

Über Verbesserungshinweise und Korrekturvorschläge sowie
Verständnisfragen zum Inhalt der FAQ freue ich mich. Ich nehme auch
allgemeine Fragen zu PostgreSQL gerne entgegen, verweise jedoch auf
die Mailing-Listen als schnelle und zuverlässige Anlaufstellen.

[[Category:FAQ]]

FAQ/de

2011-12-06T18:41:05Z

Mastermind: /* Kommt PostgreSQL mit den Anpassungen der Sommerzeit in verschiedenen Ländern klar? */

{{Languages}}

== Allgemeine Fragen ==

=== Was ist PostgreSQL? Wie wird es ausgesprochen? ===

Die (englische) Aussprache ist "Post-Gres-Q-L". Im allgemeinen
Sprachgebrauch hat sich die Kurzform "Postgres" auch durchgesetzt.
(Für diejenigen, die es interessiert: eine MP3-Datei mit der
amerikanischen Aussprache befindet sich hier:
http://www.postgresql.org/files/postgresql.mp3

PostgreSQL ist ein objektrelationales Datenbanksystem, das die Vorzüge
von kommerziellen Datenbanksystemen mit zukunftsweisenden Innovationen
kombiniert. PostgreSQL ist freie Software und dessen kompletter
Quellcode ist öffentlich verfügbar.

Die PostgreSQL-Entwicklung wird von einem Team von meist freiwilligen
Entwicklern durchgeführt. Dieses Team ist für die Gesamtentwicklung
von PostgreSQL verantwortlich. Es handelt sich um ein
Gemeinschaftsprojekt, das nicht von einer bestimmten Firma
kontrolliert wird. Lesen Sie die Entwickler-FAQ:
http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn Sie an einer
Mitarbeit interessiert sind.

=== Wer kontrolliert PostgreSQL? ===

Falls Sie nach dem Namen eines etwaigen Inhabers bzw. nach einem
allmächtigen Zentralkommittee suchen - sparen Sie sich die Mühe, sowas
existiert gar nicht. Es gibt zwar das "Core Committee" sowie
Entwickler, die CVS-Schreibberechtigung haben, jedoch haben diese
Gruppen eher nur eine administrative Rolle. Das Projekt wird durch die
Community gesteuert, die aus den Entwicklern sowie natürlich auch den
Nutzern besteht - jeder kann daran teilnehmen. (Lesen Sie die
Entwickler-FAQ: http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn
Sie an der PostgreSQL-Entwicklung teilnehmen möchten).

=== Welchem Copyright unterliegt PostgreSQL? ===

PostgreSQL wird unter der klassischen BSD-Lizenz herausgegeben. Im
Grunde genommen erlaubt diese den Nutzern, beliebig mit dem Code
umzugehen, auch der Weiterverkauf von Binärversionen ohne Quellcode
ist erlaubt. Die einzige Einschränkung besteht darin, dass PostgreSQL
auf keinen Fall für etwaige Probleme mit der Software haftet. Außerdem
muß der Copyright- Text in allen Kopien der Software enthalten sein.
Dies ist der Originaltext der BSD-Lizenz:

PostgreSQL Data Base Management System

Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group
Portions Copyright (c) 1994-6 Regents of the University of California

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose, without fee, and without a written
agreement is hereby granted, provided that the above copyright notice
and this paragraph and the following two paragraphs appear in all
copies.

IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY
FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES,
INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND
ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE
PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF
CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT,
UPDATES, ENHANCEMENTS, OR MODIFICATIONS.

Es gilt die Copyright-Klausel im Original!

=== Auf welchen Plattformen läuft PostgreSQL? ===

Normalerweise kann PostgreSQL auf jeder modernen UNIX-kompatiblen
Plattform eingesetzt werden. Diejenigen Plattformen, die bei der
jeweiligen Versionsfreigabe getestet wurden, sind in den
Installationsanleitungen aufgelistet.

PostgreSQL läuft auch auf Microsoft NT-basierten Betriebssystemen wie
Windows 2000 SP4, XP und Server 2003. Ein vorgefertigtes
Installationspaket kann von http://pgfoundry.org/projects/pginstaller
heruntergeladen werden. DOS-basierte Windows-Versionen (Win95, Win98,
WinMe) können PostgreSQL nur mit Hilfe der Cygwin-Umgebung ausführen.

=== Woher bekomme ich PostgreSQL? ===

Per Web-Browser hier: http://www.postgresql.org/ftp/ und per FTP hier:
ftp://ftp.postgresql.org/pub/.

=== Was ist die neueste Version von PostgreSQL? ===

Die neueste Version von PostgreSQL kann auf der [http://www.postgresql.org/ Website] eingesehen werden.

Die Freigabe einer neuen Hauptversion erfolgt in der Regel jährlich, kleinere Korrekturversionen alle paar Monaten. Die kleineren Updates werden "Minor"-Updates, die großen jährlich erscheinenden "Major"-Updates genannt. "Minor"-Update erscheinen in der Regel gleichzeitig für alle unterstützten "Major"-Versionen. [http://www.postgresql.org/support/versioning Falls Sie dieses Thema interessiert sollten Sie hier weiterlesen.]

=== Wo bekomme ich Support für PostgreSQL? ===

Die PostgreSQL-Community bietet Unterstützung per Mailing-Liste. Die
Web-Seite http://www.postgresql.org/community/lists/ bietet einen
Überblick. Die Listen general und bugs bieten einen guten Einstieg.

Eine deutschsprachige Mailing-Liste gibt es hier:
http://archives.postgresql.org/pgsql-de-allgemein/.

Der wichtigsten IRC-Channel ist #postgresql auf Freenode
(irc.freenode.net). Unter UNIX/Linux können Sie mit z.B. irc -c
'#postgresql' "$USER" irc.freenode.net. daran teilnehmen. Auf Freenode
gibt es folgende Channels:
* #postgresql-es (spanisch)
* #postgresqlfr (französischen)
* #postgresql-br (brasilianischen)

Es gibt außerdem einen PostgreSQL-Channel bei EFNet.

Eine Liste von Unternehmen, die Support für PostgreSQL auf kommerzieller Basis leisten, kann unter http://www.postgresql.org/support/professional_support eingesehen werden.

=== Wie kann ich einen Fehlerbericht abgeben? ===

Nutzen Sie das Formular unter
http://www.postgresql.org/support/submitbug. Schauen Sie aber vorher
unter ftp://ftp.postgresql.org/pub/ nach, ob es mittlerweile eine
neuere PostgreSQL-Version gibt, in der der Fehler behoben wurde.

Bugs, die über das Formular bzw. eine der Mailing-Listen
bekanntgegeben wurden, erhalten typischerweise einer der folgenden
Reaktionen:

* es ist kein Bug, der Grund wird benannt
* es ist ein bereits bekannter Bug, der bereits auf der TODO-Liste aufgenommen wurde
* der Bug wurde in der aktuellen Version behoben
* der Bug wurde bereits behoben, befindet sich aber noch nicht in einer offiziell veröffentlichten Version
* es wird um eingehendere Informationen gebeten, z.B.:
** Betriebssystem
** PostgreSQL-Version
** reproduzierbares Fallbeispiel
** Debugging-Information
** Debugger-Backtrace-Ausgabe
* der Bug ist neu. Folgendes könnte passieren:
** ein Patch wird erstellt und in der nächsten Version eingebaut
** der Bug kann nicht sofort behoben werden und wird auf die TODO-Liste gesetzt

=== Wie erfahre ich von bekannten Bugs oder fehlenden Features? ===

PostgreSQL unterstützt eine erweiterte Teilmenge von SQL:2003. Siehe
unsere TODO-Liste unter http://www.postgresql.org/docs/faqs.TODO.html
für eine Auflistung der bekannten Bugs, fehlenden Features und
zukünftigen Pläne.

Eine Anfrage nach einem neuen Feature führt normalerweise zu einer der
folgenden Antworten:

* das Feature ist bereits auf der TODO-Liste
* das Feature ist nicht wünschenswert, weil:
** es vorhandene Funktionalität dupliziert, welche bereits dem SQL-Standard folgt
** es würde die Komplexität der Code-Basis erhöhen, ohne nennenswerte Vorteile zu bringen
** es wäre unsicher bzw. unzuverlässig
* das neue Feature wird der TODO-Liste hinzugefügt

PostgreSQL verwendet kein Bugtracking-System, da es sich als effizienter erwiesen hat, E-Mails direkt zu beantworten und die TODO-Liste aktuell zu halten. In der Praxis werden Bugs sehr schnell beseitigt, und diejenigen Bugs, die Auswirkungen auf eine große Anzahl von Nutzern haben, werden meist kurzfristig korrigiert. Der einzige Überblick über alle Änderungen, Verbesserungen und Korrekturen in einer PostgreSQL-Version befindet sich in den CVS-Log-Meldungen. Auch die Release-Notes listen nicht jede Änderung in der Software auf.

=== Welche Dokumentation ist für PostgreSQL verfügbar? ===

PostgreSQL bietet umfangreiche Dokumentation, darunter ein großes
Handbuch, man-Pages und einige kleine Testprogramme. Siehe das /doc-
Verzeichnis. Ausserdem sind alle Handbücher online unter
http://www.postgresql.org/docs/ verfügbar.

Zwei Bücher zu PostgreSQL sind online verfügbar unter
http://www.postgresql.org/docs/books/awbook.html und
http://www.commandprompt.com/ppbook/ .

Eine Liste lieferbarer PostgreSQL-Bücher befindet sich unter
http://www.postgresql.org/docs/books Diverse technische Artikel
befinden sich unter http://www.postgresql.org/docs/techdocs .

psql hat einige nützliche \d-Befehle, um Informationen über Typen,
Operatoren, Funktionen, Aggregate, usw. zu zeigen.

Die PostgreSQL-Website enthält noch mehr Dokumentation.

=== Wie kann ich SQL lernen? ===

Die oben erwähnten PostgreSQL-spezifische Bücher bieten einen guten
Einstieg. Viele PostgreSQL-Anwender mögen "The Practical SQL Handbook"
(Bowman et al., Addison Wesley). Andere dagegen mögen "The Complete
Reference SQL" (Groff et al., McGraw-Hill).

Es gibt ausserdem einige nützliche Online-Tutorials:

* http://www.intermedia.net/support/sql/sqltut.shtm
* http://sqlcourse.com
* http://www.w3schools.com/sql/default.asp
* http://mysite.verizon.net/Graeme_Birchall/id1.html

=== Wie kann ich im Entwicklerteam mitarbeiten? ===

Lesen Sie in der Entwickler-FAQ unter
[[Developer_FAQ | Developer FAQ]] nach.

=== Wie läuft PostgreSQL im Vergleich zu anderen Datenbanksystemen? ===

Es gibt verschiedene Methoden, Software zu messen: Eigenschaften,
Performanz, Zuverlässigkeit, Support und Preis.

==== Eigenschaften ====

PostgreSQL besitzt die meisten Eigenschaften - wie
Transaktionen, Unterabfragen (Subqueries), Trigger, Views,
referenzielle Integrität bei Fremdschlüsseln und verfeinertes
Locking - die bei großen kommerziellen DBMS vorhanden sind. Es
bietet außerdem einige anderen Eigenschaften, die diese nicht
immer haben, wie benutzerbestimmte Typen, Vererbung, Regeln,
und die Multi-Versionen-Steuerung zum Verringern
konkurrierender Locks.

==== Performanz ====
Die Performanz von PostgreSQL ist mit der von kommerziellen und
anderen Open-Source-Datenbanken vergleichbar. In manchen
Bereichen ist es schneller, in anderen langsamer. In der Regel
beträgt der Unterschied +/-10%.

==== Zuverlässigkeit ====
Es ist selbstredend, dass ein DBMS wertlos ist, wenn es nicht
zuverlässig arbeitet. Daher bemühen wir uns, nur streng
geprüften und beständigen Code freizugeben, der nur ein Minimum
an Programmfehlern aufweist. Jede Freigabe hat mindestens einen
Monat Betatest-Phase hinter sich, und unsere Freigabehistorie
beweist, dass wir stabile und solide Versionen freigeben, die
im Produktionsbetrieb genutzt werden können. Wir glauben, dass
wir im Vergleich mit anderer Datenbanksoftware vorteilhaft
dastehen.

==== Support ====
Unsere Mailinglisten bieten die Möglichkeit, gemeinsam mit
einer großen Gruppe von Entwicklern und Benutzern mögliche
Probleme zu lösen. Wir können nicht immer eine Fehlerbehebung
garantieren, kommerzielle DBMS tun dies aber auch nicht. Der
direkte Kontakt zur Entwickler- und Benutzergemeinschaft und
der Zugriff auf die Handbücher und den Quellcode ermöglicht
einen im Vergleich zu anderen DBMS höherwertigeren Support. Es
gibt jedoch auch Anbieter von kommerziellen Support-Leistungen
(siehe FAQ-Punkt 1.7).

==== Preis ====
PostgreSQL ist frei verfügbar, sowohl für die kommerzielle wie
auch für die nicht-kommerzielle Nutzung. Sie können den
PostgreSQL-Code ohne Einschränkungen (außer denjenigen, die in
der oben angegebene BSD-artigen Lizenz erwähnt werden) in Ihr
Produkt integrieren.

=== Kann PostgreSQL eingebettet (embedded) werden? ===
PostgreSQL basiert auf einer Server/Client-Architektur, diese benötigt separate Prozesse für jeden Klient und Server, hinzukommen auch noch weitere "Helfer-Prozesse" (z. B. für autovacuum und stats-collector). Zwar können einige "embedded-Architekturen" diese Anforderungen erfüllen, aber wenn der Datenbank-Prozess innerhalb des Applikations-Prozesses laufen muss, kann PostgreSQL nicht verwendet werden. Dazu sollte man leichtere Datenbanken nehmen.

=== Wie kann ich mich von einer Maillingliste abmelden? Wie verhindere ich es, dass ich doppelte E-Mails bekomme? ===
Majordomo ermöglicht es sich von allen Maillinglisten an- und abzumelden, ggf. müssen Sie sich zuerst ihr Majordomo-Passwort zuschicken lassen.
[http://mail.postgresql.org/mj/mj_wwwusr PostgreSQLs Majordomo erreichen Sie hier.]

Die PostgreSQL-Maillinglisten sind so konfiguriert, dass Antworten an den ursprünglichen Autor und an die Maillingliste verschickt werden. Somit soll erreicht werden dass Benutzer immer schnellstmöglichst eine Antwort erhalten können. Diese Einstellungen können Sie auch über die Konfiguration von Majordomo ändern, ändern Sie dafür die Einstellung für ''eliminatecc''. Sie können auch einstellen dass Sie selbst keine Antwort auf Ihre eigenen E-Mails bekommen, ändern sie dafür die Einstellung für ''selfcopy''.
[http://mail.postgresql.org/mj/mj_wwwusr PostgreSQLs Majordomo erreichen Sie hier.]

== Fragen zu Benutzerprogrammen ==

=== Welche Schnittstellen gibt es für PostgreSQL? ===

Die PostgreSQL-Installation stellt nur Schnittstellen für C und
Embedded C bereit. Alle weitere Schnittstellen sind unabhängige
Projekte, die einzeln heruntergeladen werden werden müssen. Diese
Trennung ermöglicht individuelle Entwickler-Teams und
Entwicklungszyklen für die jeweiligen Projekte.

Einige Programmiersprachen wie PHP haben eine PostgreSQL-
Schnittstelle bereits eingebaut. Schnittstellen für Sprachen wie Perl,
TCL, Python und viele anderen sind unter http://gborg.postgresql.org
im Bereich Drivers/Interfaces verfügbar sowie per Internet-Suche.

=== Wie kann man PostgreSQL in einer Website nutzen? ===

Eine nette Einführung zu datenbank-gestützten Webseiten kann unter
http://www.webreview.com (engl.) eingesehen werden.

Für die Web-Integration ist PHP eine ausgezeichnete Schnittstelle. PHP
gibt es bei http://www.php.net

Desweiteren bietet sich die Perl-Schnittstelle mit CGI.pm
oder mod_perl auch an.

=== Hat PostgreSQL eine grafische Benutzerschnittstelle? ===

Es gibt eine große Anzahl von GUI-Programmen für PostgreSQL - sowohl
kommerziell als auch Open-Source. [http://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools Eine englische Liste befindet sich hier.]

== Administrative Fragen ==

=== Wie installiere ich PostgreSQL woanders als in /usr/local/pgsql? ===

Bei der Ausführung von configure die Option --prefix mit dem Zielverzeichnis angeben.

=== Wie regle ich Zugriffe von anderen Rechnern? ===

PostgreSQL ist standardmäßig so eingestellt, dass Verbindungen nur vom
lokalen Rechner über Unix Domain Sockets bzw. TCP/IP möglich sind.
Verbindungen von anderen Rechnern werden erst dann ermöglicht, wenn
Sie in der Datei postgresql.conf die Einstellung listen_addresses
anpassen, in der Datei $PGDATA/pg_hba.conf host-basierte
Authentifizierung einschalten und den Server neu starten.

=== Wie kann ich eine bessere Performanz erreichen? ===

Es gibt drei große Bereiche, in denen Performanzverbesserungen erzielt
werden können:

==== Abfrageoptimierung ====
Die Modifizierung von Abfragen kann eine bessere Performanz erzielen:

* [http://www.postgresql.org/docs/current/interactive/indexes.html Erstellung von Indexen, einschliesslich partieller Indexe sowie Expressionsindexe]
* Einsatz von COPY anstelle multipler INSERT-Anweisungen
* Gruppierung von mehreren Abfragen innerhalb einer Transaktion, um Aufwand beim Abschluss von Transaktionen einzusparen
* Einsatz von CLUSTER beim Holen von einer großen Anzahl von Datenreihen aus einem Index
* Einsatz von LIMIT, um eine Untermenge der Abfragenergebnisse zurückzuliefern
* [http://www.postgresql.org/docs/current/interactive/sql-prepare.html Einsatz von vorbereiteten Befehlen (prepared queries)]
* Einsatz von ANALYZE, um die Datenbankstatistik für den Abfragenplaner aktuell zu halten
* [http://www.postgresql.org/docs/current/static/routine-vacuuming.html Regelmäßiger Einsatz von VACUUM bzw. pg_autovacuum (autovacuum ist seit Version 8.3 standardmäßig aktiviert)]
* Bei großen Datenveränderungen die Löschung von Indexen

==== Server-Konfiguration ====
Einige Einstellungen in der Datei postgresql.conf wirken sich auf die Performanz aus. Das Handbuch enthält unter http://www.postgresql.org/docs/current/static/runtime-config.html eine komplette Auflistung.

Kommentare zu den jeweiligen Einstellungen gibt es unter http://www.varlena.com/varlena/GeneralBits/Tidbitsannotated_conf_e.html und http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html.

==== Hardware-Auswahl ====
Die Auswirkung von Hardware auf Performanz wird unter http://momjian.us/main/writings/pgsql/hw_performance/index.html und http://www.powerpostgresql.com/PerfList/ erläutert.

=== Welche Debugging-Funktionen sind für PostgreSQL verfügbar? ===

Unter den Optionen für die Server-Konfigurierung gibt es zahlreiche
log_*-Variablen, die die Ausgabe von Abfrage- und Prozessstatistiken
ermöglichen. Diese können für Debugging-Zwecke sowie Performanz-Tests
sehr nützlich sein.

=== Ich bekomme die Meldung "Sorry, too many clients", wenn ich eine Verbindung aufzubauen versuche. Warum? ===

Ihr System hat die maximal zulässige Anzahl von Datenbankverbindungen
erreicht (Voreinstellung 100). Sie müssen die maximale Anzahl der
gleichzeitig ausführbaren Backend-Prozesse hochsetzen, indem Sie in
postgresql.conf den Wert max_connections ändern und den Server
neustarten.

=== Wie wird PostgreSQL aktualisiert? ===

Allgemeine Informationen zur Aktualisierung von PostgreSQL gibt es auf
der Seite http://www.postgresql.org/support/versioning. Detaillierte
technische Informationen gibt es auf der Seite
http://www.postgresql.org/docs/current/static/install-upgrading.html

=== Kommt PostgreSQL mit den Anpassungen der Sommerzeit in verschiedenen Ländern klar? ===

Für die Berücksichtigung der Sommerzeit verwendet PostgreSQL Seit dem Release 8.0 die weiterverbreitete tzdata-Datenbank (auch bekannt als "zoneinfo database" oder "[http://www.twinsun.com/tz/tz-link.htm Olzen timezone database]".

Jedes Update von PostgreSQL beinhaltet die aktuellen tzdata Dateien, daher sollte es reichen die Minor-Updates der eingesetzten Major Version im Auge zu behalten.

Unter der Vorraussetzung dass das Betriebssystem diese Dateien schon in einer stets aktuellen Version vorbehält, ist es üblich, dass man diese Dateien verwendet. PostgreSQL bietet dazu eine compile-option an.

=== Welche Hardware eignet sich für den Betrieb mit PostgreSQL? ===

PostgreSQL läuft auf fast jeder Hardware-Kombination. Im PC-Bereich
gibt es allerdings sehr große Abweichungen in der Qualität. Für einen
Arbeitsplatz- oder Entwicklungsrechner mag dies nicht so bedeutend
sein, im Server-Betrieb jedoch lohnt sich auf jeden Fall die
Investition in teurere Bestandteile (Stichwörter ECC-Speicher, SCSI,
Hauptplatinen und Netzteile von namhaften Herstellern). Nutzen Sie
unsere Mailing-Listen, um Hardware-Optionen zu diskutieren.

== Fragen zum Betrieb ==

=== Wie wähle ich per SELECT-Anweisung nur die ersten paar Zeilen bzw. eine beliebige Zeile in einer Abfrage aus? ===

Wenn Sie bei der Ausführung der Abfrage die Anzahl der anzufordenden
Reihen bereits kennen, nutzen Sie LIMIT. Wenn die ORDER BY- Anweisung
mit einem Index verwendet wird, ist es möglich, dass die gesamte
Abfrage nicht ausgeführt werden muss. Wenn Sie die Anzahl der der
anzufordenden Reihen nicht kennen, verwenden Sie einen Cursor und
FETCH.

Um eine beliebige Zeile auszuwählen, nutzen Sie ORDER BY random():
SELECT spalte
FROM tabelle
ORDER BY random()
LIMIT 1

=== Wie finde ich heraus, welche Tabellen, Indexe, Datenbanken oder Benutzer in der Datenbank definiert sind? Wie bekomme ich die von psql verwendeten Abfragen? ===

In psql zeigt der Befehl \dt eine Liste der Datenbanktabellen. Weitere
psql-Befehle lassen sich mit \? anzeigen. Sie können sich die Datei
pgsql/src/bin/psql/describe.c mit dem Quellcode für psql ansehen. Sie
enthält die SQL-Abfragen, die die Backslash-Kommandos (\) ausführen.
Sie können psql auch mit der -E Option starten. Danach gibt psql die
Abfragen aus, die es bei der Ausführung der Befehle benutzt. Außerdem
biete PostgreSQL ein SQL-kompatibles INFORMATION SCHEMA, das
Metainformation über die Datenbank zur Verfügung stellt.

Mit psql -l können Sie alle Datenbanken anzeigen lassen.

Die Datei pgsql/src/tutorial/syscat.source enthält außerdem viele
SELECT- Abfragen, mit deren Hilfe man Information über die
Systemtabellen erhalten kann.

=== Wie ändere ich den Datentyp einer Spalte? ===

Ab Version 8.0 kann der Datentyp einer Spalte mit ALTER TABLE ALTER
COLUMN TYPE geändert werden, sofern der neue Datentyp die Werte des
alten Datentype aufnehmen kann.

Bei früheren Versionen gehen Sie wie folgt vor:
BEGIN;
ALTER TABLE tabelle ADD COLUMN neue_spalte neuer_datentyp;
UPDATE tabelle SET neue_spalte = CAST(alte_spalte AS neuer_datentyp);
ALTER TABLE tabelle DROP COLUMN alte_spalte;
COMMIT;

Um den Speicherplatz freizugeben, der von der gelöschten Spalte
verwendet wurde, führen Sie VACUUM FULL aus.

=== Was ist die Maximalgröße für eine Zeile, eine Tabelle, eine Datenbank? ===

Es bestehen folgende Obergrenzen:
Maximale Größe eine Datenbank? unbeschränkt (es existieren
Datenbanken mit 32 TB)
Maximale Größe einer Tabelle? 32 TB
Maximale Größe einer Zeile? 400 GB
Maximale Größe einer Spalte? 1 GB
Maximale Anzahl von Zeilen in einer Tabelle?
unbeschränkt
Maximale Anzahl von Spalten in einer Tabelle?
250-1600 je nach Spaltentyp
Maximale Anzahl von Indexen für eine Tabelle?
unbeschränkt

Selbstverständlich sind dies theoretische Werte, die oft durch die
verfügbaren Platten- und Speicherressourcen beschränkt werden. Extreme
Größen können zu Leistungseinbußen führen.

Die maximale Tabellengröße von 32 TB benötigt keine
Large-File-Unterstützung im Betriebssystem. Große Tabellen werden in
Dateien mit einer Größe von je 1 GB aufgeteilt, wodurch etwaige
dateisystem-bedingte Beschränkungen nicht relevant sind.

Die maximale Tabellengröße und die maximale Anzahl von Spalten können
vervierfacht werden, indem man die Default-Blockgröße auf 32 KB
heraufsetzt. Die Tabellengröße kann auch durch Tabellenpartitionierung
vergrößert werden.

Eine Einschränkung ist, dass Indexe nur auf Spalten erstellt werden
können, die bis etwa 2.000 Zeichen groß sind. Um auf größere Spalten
eine UNIQUE-Constraint setzen zu können, nutzen Sie einen funktionalen
Index mit dem MD5-Hash-Wert der Spalte. Um innerhalb einer großen, mit
Text belegten Spalte suchen zu können, verwenden Sie einen
Volltext-Index.

=== Wieviel Plattenplatz wird benötigt, um die Daten aus einer typischen Textdatei abzuspeichern? ===

Eine PostgreSQL-Datenbank kann beim Abspeichern einer einfachen
Textdatei bis zu fünfmal mehr Platz gegenüber der eigentlichen Größe
der Datei beanspruchen.

Betrachten wir eine Datei mit 100.000 Zeilen mit einem Integer und
einer Textbeschreibung pro Zeile. Gehen wir davon aus, dass die
durchschnittliche Länge der Textbeschreibung 20 Byte beträgt. Die
einfache Datei würde 2,8 MB groß sein. Die Größe der
PostgreSQL-Datenbankdatei, die diese Daten enthält, liegt ungefähr bei
5,2 MB:
24 Bytes: jeder Zeilenkopf (ungefähr)
+24 Bytes: ein Integer-Feld und ein Textfeld
+ 4 Bytes: Zeiger auf der Datenseite auf den Tupel
-----------------------------------------------
52 Bytes pro Zeile

Die Größe einer Datenseite in PostgreSQL beträgt 8192 Bytes (8 KB),
also:
8192 Bytes pro Seite
--------------------- = 146 Zeilen pro Seite (abgerundet)
52 Bytes pro Zeile

100.000 Datenzeilen
------------------------ = 685 Datenbankseiten (aufgerundet)
158 Zeilen pro Seite

633 Datenbankseiten * 8192 Bytes pro Seite = 5,185,536 bytes (5,2 MB)

Indexe beanspruchen nicht so viel Platz. Da sie jedoch die Daten
beinhalten, die sie indizieren, können auch sie sehr groß werden.

NULL-Werte werden als Bitmaps gespeichert, wodurch sie sehr wenig
Platz in Anspruch nehmen.

=== Meine Abfragen sind langsam oder benutzen die Indexe nicht. Warum? ===

Indexe werden nicht automatisch bei jeder Abfrage verwendet. Indexe
werden nur dann verwendet, wenn die abzufragende Tabelle eine
bestimmte Größe übersteigt, und die Abfrage nur eine kleine
Prozentzahl der Tabellenzeilen abfragt. Der Grund hierfür ist der,
dass die durch einen Index verursachten Festplattenzugriffe manchmal
länger dauern würden als ein einfaches Auslesen aller Tabellenzeilen
(sequentieller Scan).

Um festzustellen, ob ein Index verwendet werden soll, braucht
PostgreSQL Statistiken über die Tabelle. Diese Statistiken werden
durch die Anweisungen VACUUM ANALYZE bzw. ANALYZE berechnet. Anhand
der Statistiken kennt der Abfragenoptimierer die Anzahl der
Tabellenzeilen und kann besser entscheiden, ob Indexe verwendet werden
sollen. Statistiken sind auch bei der Ermittlung der optimalen
JOIN-Reihenfolgen und -Methoden wertvoll. Daher sollten diese
regelmässig durchgeführt werden, da sich der Inhalt einer Tabelle ja
auch verändert.

Indexe werden normalerweise nicht in ORDER BY-Abfrage oder in JOINs
verwendet. Ein sequentieller Scan mit anschließendem explizitem
Sortiervorgang ist normalerweise schneller als ein Index-Scan einer
großen Tabelle. Jedoch wird bei einer Abfrage, in der LIMIT zusammen
mit ORDER BY verwendet wird, oftmals ein Index verwendet, da nur ein
kleiner Abschnitt der Tabelle zurückgeliefert wird.

Sollte es danach aussehen, also ob der Optimierer irrtümlich einen
sequentiellen Scan ausführt, führen Sie SET enable_seqscan TO 'off'
aus und prüfen Sie, ob die Indexabfrage dadurch scheller geworden ist.

Bei der Nutzung von Wildcard-Operatoren wie LIKE oder ~, können Indexe
nur unter bestimmten Umständen verwendet werden:

* Das Suchmuster muss sich an Anfang des Strings befinden, d.h.:
** LIKE-Suchmuster dürfen nicht mit % anfangen;
** ~ (reguläre Ausdrücke) müssen mit ^ anfangen.
* Das Suchmuster darf nicht mit einer Zeichenklasse (z.B. [a-e]) beginnen.
* Suchmuster, die Gross- und Kleinschreibung nicht berücksichtigen (z.B. ILIKE bzw. ~*), verwenden keine Indexe. Stattdessen können funktionale Indexe verwendet werden, die im Punkt 4.8 beschrieben werden.
* Die Standard-Locale "C" muss während der Datenbank-Initialisierung mit initdb verwendet worden sein, da andere locales den nächstgrößten Wert nicht ermitteln können. Es ist allerdings möglich, einen besonderen text_pattern_ops-Index für solche Fälle zu erstellen.

In Versionen vor 8.0 werden Indexe oft nicht benutzt, wenn die
jeweiligen Datentypen nicht genau übereinstimmen. Dies gilt besonders
für Indexe auf Spalten mit den Datentypen INT2, INT8 und NUMERIC

=== Auf welche Weise kann ich sehen, wie der Abfrage-Optimierer meine Abfrage auswertet? ===

Eine ausführliche Erklärung zu diesem Thema findet sich in der [http://www.postgresql.org/docs/current/static/sql-explain.html EXPLAIN] Dokumentation.

=== Wie änder ich das Sortierverhalten von textähnlichen Daten? ===
PostgreSQL sortiert Daten anhand dem bei initdb gesetzten Locale. (Ab 8.4 wird es es möglich sein pro Datenbank ein eigenes Locale zu definieren)

Entspricht das Sortierverhalten nicht dem gewünschten muss man die Locale ändern. Die meisten Locales, außer "C", sortieren anhand der Reihenfolge des entsprechenden Wörterbuches. Das Locale "C" ignoriert jegliche Punktuation und Zwischenraum.

=== Wie verfahre ich bei der Suche mit regulären Ausdrücken und bei einer Suche, bei der Groß- und Kleinschreibweisen ignoriert werden? Wie verwende ich einen Index bei solchen Suchabfragen? ===

Der Operator ~ wendet einen regulären Ausdruck an und ~* wendet ihn
an, ohne die Groß- und Kleinschreibung zu beachten. Ebenso beachtet
LIKE die Groß- und Kleinschreibung, und ILIKE nicht.

Gleichheitsvergleiche, die Groß- und Kleinschreibung ignorieren,
werden in der Regel so ausgedruckt:
SELECT *
FROM tabelle
WHERE LOWER(spalte) = 'abc'

Hier wird kein normaler Index benutzt. Legt man hingegen einen
funktionalen Index an, so wird er auf jeden Fall verwendet:
CREATE INDEX tabelle_index ON tabelle (LOWER(spalte))

Falls der obige Index als einen UNIQUE-Index angelegt wird, können
keine Werte in die Spalte eingefügt werden, die sich nur durch ihre
Groß- und Kleinschreibung unterscheiden. Um Fehler zu vermeiden muß
ein CHECK-Constraint oder ein Trigger eingesetzt werden.

=== Wie ermittle ich in einer Abfrage, ob ein Feld NULL ist? Kann nach der NULL-Belegung sortiert werden? ===

Testen Sie die Spalte mit IS NULL bzw. IS NOT NULL.
SELECT
*
FROM
tabelle
WHERE
spalte IS NULL

Beim konkatenieren mit einen NULL-Wert wir das Ergebnis auch NULL. Um dies zu verhindern verwenden Sie am besten [http://www.postgresql.org/docs/current/static/functions-conditional.html| COALESCE()]
SELECT
COALESCE(col1, '') || COALESCE(col2, '')
FROM tab;

Um die Spalte danach zu sortieren, ob sie mit NULL belegt ist oder nicht, verwenden Sie die Bedingungen IS NULL bzw. IS NOT NULL in der ORDER BY-Klausel. Da Bedingungen, die wahr sind, höher als das Gegenteil sortiert werden, bewirkt die folgende Abfrage, dass die NULL-Spalten zuerst gelistet werden:
SELECT
*
FROM
tabelle
ORDER BY
(spalte IS NOT NULL)

Ab PostreSQL 8.3 und höher, ist es möglich das standardisierte NULLS FIRST/NULLS LAST zu verwenden um die Position der NULL-Werte im Ergebnis zu bestimmen. (bei FIRST stehen diese zu erst, bei LAST am Ende)
SELECT
*
FROM
tab
ORDER BY
col NULLS FIRST;

=== Was ist der Unterschied zwischen den verschiedenen CHAR-Typen? ===
{| border="1"
!Typ
!interner Name
!Bemerkungen
|-
|VARCHAR(n)
|varchar
|die Größe legt die Maximallänge fest; kein Auffüllen mit Leerzeichen
|-
|CHAR(n)
|bpchar
|mit Leerzeichen gefüllt bis zur angegebenen Länge
|-
|TEXT
|text
|keine obere Grenze für die Länge
|-
|BYTEA
|bytea
|Bytearray mit variabler Länge (auch für '\0'-Bytes geeignet)
|-
|"char" (with the quotes)
|char
|ein Zeichen
|}

Der interne Name kommt vor allem in den Systemkatalogen und in manchen
Fehlermeldungen vor.

Die ersten vier Typen sind "varlena"-Typen (d.h. die ersten vier Bytes
geben die Länge an, gefolgt von den Daten). Daher ist der tatsächlich
belegte Platz immer etwas mehr als die deklarierte Feldgröße.
Allerdings wird unter Umständen auf diese Datentypen Datenkompression
durch das TOAST- Verfahren angewendet, womit der tatsächlich belegte
Platz auch geringer als erwartet ausfallen kann.

Für die Speicherung von Zeichenketten variabler Länge empfiehlt sich
VARCHAR(n). Die maximale Länge eines VARCHAR(n)-Felds wird bei der
Tabellendefinition festgelegt. TEXT setzt keine Längengrenze,
allerdings gibt es eine systembedingte Obergrenze von 1 GB.

CHAR(n) ist geeignet für die Speicherung von Zeichenketten, die alle
die gleiche Länge haben. Bitte beachten Sie, dass CHAR(n) automatisch
Zeichenketten bis zur definierten Feldlänge mit Leerzeichen ausfüllt,
während bei VARCHAR(n) nur die tatsächlich eingegebene Zeichenkette
gespeichert wird.

BYTEA ist für binäre Daten, besonders für Werte, die NULL-Bytes haben.

Alle der hier erwähnten Typen weisen ähnliche Performanzeigenschaften
auf.

=== Wie erzeuge ich ein serielles Feld mit automatischer Erhöhung des Wert? ===

PostgreSQL bietet einen SERIAL-Datentyp. Dies ist zwar kein richtiger Datentyp. Es ist die Kurzform für das Erstellen einer Spalte vom Typ Integer, die von einer Sequenz befüllt wird.

Zum Beispiel:
CREATE TABLE person (
id SERIAL,
name TEXT
)

wird automatisch in:
CREATE SEQUENCE person_id_seq;
CREATE TABLE person (
id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
name TEXT
);

umgewandelt.

Die automatisch generierte Sequenz besitzt immer folgenden Namen:
''tabellederspalte''-''namederspalte''_seq

Die Man-Page zu CREATE SEQUENCE beinhaltet mehr Informationen zu Sequenzen.

Es gibt auch einen Typ BIGSERIAL, dieser unterscheidet sich aber nur darin dass die Spalte den Typ BIGINTEGER bekommt. BIGSERIAL sollte verwendet werden wenn es zu erwarten ist, dass mehr als 2 Milliarden Sequenz-Werte verwendet werden.

=== Wie bekomme ich den Wert einer SERIAL-Sequenz? ===

Eine Möglichkeit wäre, mit der nextval()-Funktion den nächsten SERIAL-Wert von dem Sequenzobjekt vor der Auszuführung einer INSERT-Anweisung anzufordern und ihn dann explizit in die INSERT-Anweisung einzubinden. Anhand der Beispieltabelle in 4.11.1 könnte dieser Vorgang in einer Pseudosprache so aussehen:

new_id = output of execute("SELECT nextval('person_id_seq')");
execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");

Danach stünde der neue Wert in der Variablen new_id für die Verwendung in weiteren Abfragen zur Verfügung, zum Beispiel als Fremdschlüssel zur Tabelle 'person'). Bitte beachten Sie, dass der Name des automatisch erstellten SEQUENCE-Objektes folgenden Name hat: «table»_«serialcolumn»_seq wobei 'table' und 'serialcolumn' die Namen
der jeweils betreffenden Tabelle / Spalte darstellen.

Als weitere Möglichkeit können Sie nach einer INSERT-Anweisung den automatisch eingefügten SERIAL-Wert mit der currval()-Funktion zurückgeben lassen:

execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
new_id = output of execute("SELECT currval('person_id_seq')");

Die einfachste Möglichkeit ist es RETURNING zu verwenden. Ein einfaches Beispiel sähe so aus:
INSERT INTO person (name) VALUES ('Blaise Pascal') RETURNING id;

=== Führt currval() zu einer Race-Condition mit anderen Nutzern? ===

Nein. currval() liefert einen Wert zurück, der von Ihrer
Datenbank-Session bestimmt wird, und der anderen Sessionen nicht zur
Verfügung steht.

=== Warum werden die Sequenzwerte nach einem Transaktionsabbruch nicht zurückgesetzt? Warum gibt es Lücken in der Nummerierung meiner Sequenz-/SERIAL-Spalte? ===

Um die gleichzeitige Abarbeitung von Transaktionen zu verbessern,
werden Sequenzen gerade nicht für andere Transaktionen gesperrt,
sondern die Sequenznummern werden den laufenden Transaktionen sofort
zugeteilt. Lücken in der Sequenznummerierung werden durch abgebrochene
Transaktionen verursacht.

=== Was ist ein OID? ===

Jede Zeile, die in PostgreSQL erzeugt wird, bekommt eine eindeutige OID, sofern die Tabelle nicht mit der Option WITHOUT OIDS angelegt wurde. OIDs sind automatisch zugewiesene 4-Byte-Integer, die innerhalb der gesamten Datenbank einmalig sind. Allerdings laufen sie bei einem Wert von ungefähr 4 Milliarden über. PostgreSQL verwendet OIDs, um
seine interne Systemtabellen zu verbinden.

Um einmalige Idenfikatoren in Datentabellen zu erstellen, wird allerdings empfohlen, statt OIDs Werte zu verwenden, die von SERIAL-Sequenzen erzeugt werden. SERIAL-Sequenzen sind innerhalb einer Tabelle einmalig und daher weniger anfällig für Überläufe. Außerdem können 8-Byte-Sequenzwerte mit BIGSERIAL (SERIAL8) erzeugt werden.

=== Was ist ein CTID? ===

CTIDs werden benutzt, um bestimmte physikalische Zeilen durch Block und Offset Werte zu identifizieren. CTIDs verändern sich, sobald Zeilen verändert oder zurückgeladen werden. Sie werden in Indexeinträgen benutzt um auf die physikalischen Zeilen zu zeigen.

=== Wieso bekomme ich einen Fehler: "ERROR: Memory exhausted in AllocSetAlloc()"? ===

Wahrscheinlich gibt es keinen virtuellen Speicher mehr in Ihrem System
oder Ihr Kernel hat niedrige Höchstgrenzen für bestimmte Ressourcen.
Probieren Sie vor dem Start von postmaster folgendes:
ulimit -d 262144
limit datasize 256m

Je nach benutzter Shell wird nur einer dieser Befehle erfolgreich
ausgeführt werden. Auf jedem Fall wird die Grenze des Datensegments
für Prozesse erhöht werden und eventuell die erfolgreiche Ausführung
der Abfrage ermöglichen. Falls Sie ein Problem mit dem SQL-Client
haben, weil das Backend zu viele Daten zurückliefert, versuchen Sie
dies vor dem Start des SQL-Clients.

=== Wie kann ich feststellen, welche PostgreSQL-Version bei mir läuft? ===

Geben Sie in psql SELECT VERSION(); ein.

=== Wie kann ich eine Spalte erstellen, deren Default-Wert immer die aktuelle Uhrzeit enthalten soll? ===

Dazu verwenden Sie CURRENT_TIMESTAMP:
CREATE TABLE test (x INT, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

=== Wie führe ich eine OUTER JOIN durch? ===

PostgreSQL unterstützt OUTER JOINs nach dem SQL- Standardsyntax. Hier
zwei Beispiele:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 ON (t1.spalte = t2.spalte)

bzw.:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 USING (spalte)

Diese identischen Abfragen verknüpfen tabelle_1 mit tabelle_2 über die
Spalte 'spalte' und geben außerdem alle unverknüpften Zeilen in
tabelle_1 (diejenigen, die keine Entsprechung in tabelle_2 haben)
zurück. Ein RIGHT JOIN würde hingegen alle unverknüpften Zeilen in
tabelle_2 hinzufügen und ein FULL JOIN würde alle verknüpften Zeilen
sowie jeweils alle unverknüpften Zeilen aus den beiden Tabellen
zurückliefern. Die Angabe von OUTER ist nicht zwingend und kann in
LEFT, RIGHT und FULL-Verknüpfungen weggelassen werden. Normale
Verknüpfungen sind INNER JOINs.

=== Wie kann ich Abfragen über mehrere Datenbanken hinweg ausführen? ===

Es gibt keinen Weg, innerhalb einer Abfrage auf mehr als eine
Datenbank zuzugreifen. Da PostgreSQL datenbank-spezifische
Systemkataloge lädt, ist eine datenbankübergreifende Abfrage nicht
möglich.

contrib/dblink ist eine Erweiterung, die datenbankübergreifende
Abfragen über Funktionsaufrufe ermöglicht.

=== Wie kann ich mehrere Zeilen bzw. Spalten von einer Funktion zurückgeben lassen? ===

Funktionen können mehrere Zeilen und Spalten zurückgeben, vgl.:
http://www.postgresql.org/docs/techdocs.17.

=== Warum bekomme ich eine Fehlermeldung wie "relation with OID ##### does not exist" wenn ich temporäre Tabellen in PL/PgSQL-Funktionen benutze? ===

In PostgreSQL-Versionen vor 8.3 verarbeitet PL/PgSQL Funktionen in
einer Cache. Dies hat eine unangenehme Nebenwirkung, nämlich dass wenn
eine PL/PgSQL-Funktion auf eine temporäre Tabelle zugreift, und diese
Tabelle anschließend gelöscht bzw. neu erstellt wird, die Funktion
fehlschlagen wird, da die gecachten Funktionsinhalte noch auf die alte
temporäre Tabelle zeigen. Die Lösung für diese Probleme besteht darin,
in der PL/PgSQL- Funktion mittels EXECUTE auf temporäre Tabellen
zuzugreifen. Dies bewirkt, dass bei jedem Funktionsruf die betreffende
Abfrage neu geparst wird.

Dieses Problem taucht in PostgreSQL 8.3 und späteren Versionen nicht
mehr auf.

=== Welche Replikationslösungen gibt es? ===

Der Begriff "replikation" umfasst mehrere verschiedene Technologien,
jede mit eigenen Vor- und Nachteilen. [http://www.postgresql.org/docs/8.3/static/high-availability.html| Die Dokumentation enthält eine gute Einführung in das Thema Replikation]

Mit "Master/slave"-Replikation werden Änderungen in einer
Hauptdatenbank durchgeführt und an "Sklaven" verteilt, die im
Nur-Lese-Modus arbeiten. Die populärste Lösung für PostgreSQL ist
Slony-I.

"Multi-master replication" ermöglicht sowohl lesende als auch
schreibende Zugriffe über mehrere Datenbank-Server hinweg. Allerdings
hat diese Art von Replikation eine negative Auswirkung auf die
Performanz durch die Notwendigkeit, Änderungen zwischen Servern zu
synchronisieren. Pgcluster ist die populärste freie Lösung für
PostgreSQL.

Es gibt auch einige kommerzielle und hardware-basierte
Replikationslösungen für verschiedene Arten der Replikation.

=== Warum werden die Tabellen- und Spaltennamen in meiner Abfrage nicht erkannt? Warum werden Großbuchstaben umgewandelt? ===

Die häufigste Ursache ist die Verwendung von Gänsefüßchen bei der
Anlegung von Tabellen, z.B.:
CREATE TABLE "Tabelle"
("SPALTE1" INT)

Dadurch werden Tabellen- und Spaltennamen (sog. Identifikatoren) in
genau der Schreibweise gespeichert (vgl. Dokumentation), was dazu
führt, dass man sie danach immer in Gänsefüßchen angeben muss. Im
obigen Beispiel muss man also immer etwa SELECT * FROM "Tabelle"
verwenden. Um dieses Problem zu vermeiden, müssen Sie immer eines der
folgenden Punkte beachten:

* bei der Tabellenanlegung keine Gänsefüßchen verwenden;
* in Identifikatoren nur Kleinschreibung verwenden;
* immer Identifikatoren mit Gänsefüßchen versehen

== Anmerkungen des Übersetzers ==

Die englische Vorlage dieser FAQ wird ständig überarbeitet. Daher
liegt die Übersetzung nicht immer auf dem aktuellsten Stand.

Die aktuellste Version der deutschen Übersetzung befindet sich immer
unter http://sql-info.de/de/postgresql/FAQ_german.html. Diese
"Arbeitsversion" enthält eventuell Änderungen, die noch nicht auf der
PostgreSQL-Website eingebunden worden sind.

Über Verbesserungshinweise und Korrekturvorschläge sowie
Verständnisfragen zum Inhalt der FAQ freue ich mich. Ich nehme auch
allgemeine Fragen zu PostgreSQL gerne entgegen, verweise jedoch auf
die Mailing-Listen als schnelle und zuverlässige Anlaufstellen.

[[Category:FAQ]]

FAQ/de

2011-12-06T18:40:28Z

Mastermind: /* Hat PostgreSQL eine grafische Benutzerschnittstelle? */

{{Languages}}

== Allgemeine Fragen ==

=== Was ist PostgreSQL? Wie wird es ausgesprochen? ===

Die (englische) Aussprache ist "Post-Gres-Q-L". Im allgemeinen
Sprachgebrauch hat sich die Kurzform "Postgres" auch durchgesetzt.
(Für diejenigen, die es interessiert: eine MP3-Datei mit der
amerikanischen Aussprache befindet sich hier:
http://www.postgresql.org/files/postgresql.mp3

PostgreSQL ist ein objektrelationales Datenbanksystem, das die Vorzüge
von kommerziellen Datenbanksystemen mit zukunftsweisenden Innovationen
kombiniert. PostgreSQL ist freie Software und dessen kompletter
Quellcode ist öffentlich verfügbar.

Die PostgreSQL-Entwicklung wird von einem Team von meist freiwilligen
Entwicklern durchgeführt. Dieses Team ist für die Gesamtentwicklung
von PostgreSQL verantwortlich. Es handelt sich um ein
Gemeinschaftsprojekt, das nicht von einer bestimmten Firma
kontrolliert wird. Lesen Sie die Entwickler-FAQ:
http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn Sie an einer
Mitarbeit interessiert sind.

=== Wer kontrolliert PostgreSQL? ===

Falls Sie nach dem Namen eines etwaigen Inhabers bzw. nach einem
allmächtigen Zentralkommittee suchen - sparen Sie sich die Mühe, sowas
existiert gar nicht. Es gibt zwar das "Core Committee" sowie
Entwickler, die CVS-Schreibberechtigung haben, jedoch haben diese
Gruppen eher nur eine administrative Rolle. Das Projekt wird durch die
Community gesteuert, die aus den Entwicklern sowie natürlich auch den
Nutzern besteht - jeder kann daran teilnehmen. (Lesen Sie die
Entwickler-FAQ: http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn
Sie an der PostgreSQL-Entwicklung teilnehmen möchten).

=== Welchem Copyright unterliegt PostgreSQL? ===

PostgreSQL wird unter der klassischen BSD-Lizenz herausgegeben. Im
Grunde genommen erlaubt diese den Nutzern, beliebig mit dem Code
umzugehen, auch der Weiterverkauf von Binärversionen ohne Quellcode
ist erlaubt. Die einzige Einschränkung besteht darin, dass PostgreSQL
auf keinen Fall für etwaige Probleme mit der Software haftet. Außerdem
muß der Copyright- Text in allen Kopien der Software enthalten sein.
Dies ist der Originaltext der BSD-Lizenz:

PostgreSQL Data Base Management System

Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group
Portions Copyright (c) 1994-6 Regents of the University of California

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose, without fee, and without a written
agreement is hereby granted, provided that the above copyright notice
and this paragraph and the following two paragraphs appear in all
copies.

IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY
FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES,
INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND
ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE
PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF
CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT,
UPDATES, ENHANCEMENTS, OR MODIFICATIONS.

Es gilt die Copyright-Klausel im Original!

=== Auf welchen Plattformen läuft PostgreSQL? ===

Normalerweise kann PostgreSQL auf jeder modernen UNIX-kompatiblen
Plattform eingesetzt werden. Diejenigen Plattformen, die bei der
jeweiligen Versionsfreigabe getestet wurden, sind in den
Installationsanleitungen aufgelistet.

PostgreSQL läuft auch auf Microsoft NT-basierten Betriebssystemen wie
Windows 2000 SP4, XP und Server 2003. Ein vorgefertigtes
Installationspaket kann von http://pgfoundry.org/projects/pginstaller
heruntergeladen werden. DOS-basierte Windows-Versionen (Win95, Win98,
WinMe) können PostgreSQL nur mit Hilfe der Cygwin-Umgebung ausführen.

=== Woher bekomme ich PostgreSQL? ===

Per Web-Browser hier: http://www.postgresql.org/ftp/ und per FTP hier:
ftp://ftp.postgresql.org/pub/.

=== Was ist die neueste Version von PostgreSQL? ===

Die neueste Version von PostgreSQL kann auf der [http://www.postgresql.org/ Website] eingesehen werden.

Die Freigabe einer neuen Hauptversion erfolgt in der Regel jährlich, kleinere Korrekturversionen alle paar Monaten. Die kleineren Updates werden "Minor"-Updates, die großen jährlich erscheinenden "Major"-Updates genannt. "Minor"-Update erscheinen in der Regel gleichzeitig für alle unterstützten "Major"-Versionen. [http://www.postgresql.org/support/versioning Falls Sie dieses Thema interessiert sollten Sie hier weiterlesen.]

=== Wo bekomme ich Support für PostgreSQL? ===

Die PostgreSQL-Community bietet Unterstützung per Mailing-Liste. Die
Web-Seite http://www.postgresql.org/community/lists/ bietet einen
Überblick. Die Listen general und bugs bieten einen guten Einstieg.

Eine deutschsprachige Mailing-Liste gibt es hier:
http://archives.postgresql.org/pgsql-de-allgemein/.

Der wichtigsten IRC-Channel ist #postgresql auf Freenode
(irc.freenode.net). Unter UNIX/Linux können Sie mit z.B. irc -c
'#postgresql' "$USER" irc.freenode.net. daran teilnehmen. Auf Freenode
gibt es folgende Channels:
* #postgresql-es (spanisch)
* #postgresqlfr (französischen)
* #postgresql-br (brasilianischen)

Es gibt außerdem einen PostgreSQL-Channel bei EFNet.

Eine Liste von Unternehmen, die Support für PostgreSQL auf kommerzieller Basis leisten, kann unter http://www.postgresql.org/support/professional_support eingesehen werden.

=== Wie kann ich einen Fehlerbericht abgeben? ===

Nutzen Sie das Formular unter
http://www.postgresql.org/support/submitbug. Schauen Sie aber vorher
unter ftp://ftp.postgresql.org/pub/ nach, ob es mittlerweile eine
neuere PostgreSQL-Version gibt, in der der Fehler behoben wurde.

Bugs, die über das Formular bzw. eine der Mailing-Listen
bekanntgegeben wurden, erhalten typischerweise einer der folgenden
Reaktionen:

* es ist kein Bug, der Grund wird benannt
* es ist ein bereits bekannter Bug, der bereits auf der TODO-Liste aufgenommen wurde
* der Bug wurde in der aktuellen Version behoben
* der Bug wurde bereits behoben, befindet sich aber noch nicht in einer offiziell veröffentlichten Version
* es wird um eingehendere Informationen gebeten, z.B.:
** Betriebssystem
** PostgreSQL-Version
** reproduzierbares Fallbeispiel
** Debugging-Information
** Debugger-Backtrace-Ausgabe
* der Bug ist neu. Folgendes könnte passieren:
** ein Patch wird erstellt und in der nächsten Version eingebaut
** der Bug kann nicht sofort behoben werden und wird auf die TODO-Liste gesetzt

=== Wie erfahre ich von bekannten Bugs oder fehlenden Features? ===

PostgreSQL unterstützt eine erweiterte Teilmenge von SQL:2003. Siehe
unsere TODO-Liste unter http://www.postgresql.org/docs/faqs.TODO.html
für eine Auflistung der bekannten Bugs, fehlenden Features und
zukünftigen Pläne.

Eine Anfrage nach einem neuen Feature führt normalerweise zu einer der
folgenden Antworten:

* das Feature ist bereits auf der TODO-Liste
* das Feature ist nicht wünschenswert, weil:
** es vorhandene Funktionalität dupliziert, welche bereits dem SQL-Standard folgt
** es würde die Komplexität der Code-Basis erhöhen, ohne nennenswerte Vorteile zu bringen
** es wäre unsicher bzw. unzuverlässig
* das neue Feature wird der TODO-Liste hinzugefügt

PostgreSQL verwendet kein Bugtracking-System, da es sich als effizienter erwiesen hat, E-Mails direkt zu beantworten und die TODO-Liste aktuell zu halten. In der Praxis werden Bugs sehr schnell beseitigt, und diejenigen Bugs, die Auswirkungen auf eine große Anzahl von Nutzern haben, werden meist kurzfristig korrigiert. Der einzige Überblick über alle Änderungen, Verbesserungen und Korrekturen in einer PostgreSQL-Version befindet sich in den CVS-Log-Meldungen. Auch die Release-Notes listen nicht jede Änderung in der Software auf.

=== Welche Dokumentation ist für PostgreSQL verfügbar? ===

PostgreSQL bietet umfangreiche Dokumentation, darunter ein großes
Handbuch, man-Pages und einige kleine Testprogramme. Siehe das /doc-
Verzeichnis. Ausserdem sind alle Handbücher online unter
http://www.postgresql.org/docs/ verfügbar.

Zwei Bücher zu PostgreSQL sind online verfügbar unter
http://www.postgresql.org/docs/books/awbook.html und
http://www.commandprompt.com/ppbook/ .

Eine Liste lieferbarer PostgreSQL-Bücher befindet sich unter
http://www.postgresql.org/docs/books Diverse technische Artikel
befinden sich unter http://www.postgresql.org/docs/techdocs .

psql hat einige nützliche \d-Befehle, um Informationen über Typen,
Operatoren, Funktionen, Aggregate, usw. zu zeigen.

Die PostgreSQL-Website enthält noch mehr Dokumentation.

=== Wie kann ich SQL lernen? ===

Die oben erwähnten PostgreSQL-spezifische Bücher bieten einen guten
Einstieg. Viele PostgreSQL-Anwender mögen "The Practical SQL Handbook"
(Bowman et al., Addison Wesley). Andere dagegen mögen "The Complete
Reference SQL" (Groff et al., McGraw-Hill).

Es gibt ausserdem einige nützliche Online-Tutorials:

* http://www.intermedia.net/support/sql/sqltut.shtm
* http://sqlcourse.com
* http://www.w3schools.com/sql/default.asp
* http://mysite.verizon.net/Graeme_Birchall/id1.html

=== Wie kann ich im Entwicklerteam mitarbeiten? ===

Lesen Sie in der Entwickler-FAQ unter
[[Developer_FAQ | Developer FAQ]] nach.

=== Wie läuft PostgreSQL im Vergleich zu anderen Datenbanksystemen? ===

Es gibt verschiedene Methoden, Software zu messen: Eigenschaften,
Performanz, Zuverlässigkeit, Support und Preis.

==== Eigenschaften ====

PostgreSQL besitzt die meisten Eigenschaften - wie
Transaktionen, Unterabfragen (Subqueries), Trigger, Views,
referenzielle Integrität bei Fremdschlüsseln und verfeinertes
Locking - die bei großen kommerziellen DBMS vorhanden sind. Es
bietet außerdem einige anderen Eigenschaften, die diese nicht
immer haben, wie benutzerbestimmte Typen, Vererbung, Regeln,
und die Multi-Versionen-Steuerung zum Verringern
konkurrierender Locks.

==== Performanz ====
Die Performanz von PostgreSQL ist mit der von kommerziellen und
anderen Open-Source-Datenbanken vergleichbar. In manchen
Bereichen ist es schneller, in anderen langsamer. In der Regel
beträgt der Unterschied +/-10%.

==== Zuverlässigkeit ====
Es ist selbstredend, dass ein DBMS wertlos ist, wenn es nicht
zuverlässig arbeitet. Daher bemühen wir uns, nur streng
geprüften und beständigen Code freizugeben, der nur ein Minimum
an Programmfehlern aufweist. Jede Freigabe hat mindestens einen
Monat Betatest-Phase hinter sich, und unsere Freigabehistorie
beweist, dass wir stabile und solide Versionen freigeben, die
im Produktionsbetrieb genutzt werden können. Wir glauben, dass
wir im Vergleich mit anderer Datenbanksoftware vorteilhaft
dastehen.

==== Support ====
Unsere Mailinglisten bieten die Möglichkeit, gemeinsam mit
einer großen Gruppe von Entwicklern und Benutzern mögliche
Probleme zu lösen. Wir können nicht immer eine Fehlerbehebung
garantieren, kommerzielle DBMS tun dies aber auch nicht. Der
direkte Kontakt zur Entwickler- und Benutzergemeinschaft und
der Zugriff auf die Handbücher und den Quellcode ermöglicht
einen im Vergleich zu anderen DBMS höherwertigeren Support. Es
gibt jedoch auch Anbieter von kommerziellen Support-Leistungen
(siehe FAQ-Punkt 1.7).

==== Preis ====
PostgreSQL ist frei verfügbar, sowohl für die kommerzielle wie
auch für die nicht-kommerzielle Nutzung. Sie können den
PostgreSQL-Code ohne Einschränkungen (außer denjenigen, die in
der oben angegebene BSD-artigen Lizenz erwähnt werden) in Ihr
Produkt integrieren.

=== Kann PostgreSQL eingebettet (embedded) werden? ===
PostgreSQL basiert auf einer Server/Client-Architektur, diese benötigt separate Prozesse für jeden Klient und Server, hinzukommen auch noch weitere "Helfer-Prozesse" (z. B. für autovacuum und stats-collector). Zwar können einige "embedded-Architekturen" diese Anforderungen erfüllen, aber wenn der Datenbank-Prozess innerhalb des Applikations-Prozesses laufen muss, kann PostgreSQL nicht verwendet werden. Dazu sollte man leichtere Datenbanken nehmen.

=== Wie kann ich mich von einer Maillingliste abmelden? Wie verhindere ich es, dass ich doppelte E-Mails bekomme? ===
Majordomo ermöglicht es sich von allen Maillinglisten an- und abzumelden, ggf. müssen Sie sich zuerst ihr Majordomo-Passwort zuschicken lassen.
[http://mail.postgresql.org/mj/mj_wwwusr PostgreSQLs Majordomo erreichen Sie hier.]

Die PostgreSQL-Maillinglisten sind so konfiguriert, dass Antworten an den ursprünglichen Autor und an die Maillingliste verschickt werden. Somit soll erreicht werden dass Benutzer immer schnellstmöglichst eine Antwort erhalten können. Diese Einstellungen können Sie auch über die Konfiguration von Majordomo ändern, ändern Sie dafür die Einstellung für ''eliminatecc''. Sie können auch einstellen dass Sie selbst keine Antwort auf Ihre eigenen E-Mails bekommen, ändern sie dafür die Einstellung für ''selfcopy''.
[http://mail.postgresql.org/mj/mj_wwwusr PostgreSQLs Majordomo erreichen Sie hier.]

== Fragen zu Benutzerprogrammen ==

=== Welche Schnittstellen gibt es für PostgreSQL? ===

Die PostgreSQL-Installation stellt nur Schnittstellen für C und
Embedded C bereit. Alle weitere Schnittstellen sind unabhängige
Projekte, die einzeln heruntergeladen werden werden müssen. Diese
Trennung ermöglicht individuelle Entwickler-Teams und
Entwicklungszyklen für die jeweiligen Projekte.

Einige Programmiersprachen wie PHP haben eine PostgreSQL-
Schnittstelle bereits eingebaut. Schnittstellen für Sprachen wie Perl,
TCL, Python und viele anderen sind unter http://gborg.postgresql.org
im Bereich Drivers/Interfaces verfügbar sowie per Internet-Suche.

=== Wie kann man PostgreSQL in einer Website nutzen? ===

Eine nette Einführung zu datenbank-gestützten Webseiten kann unter
http://www.webreview.com (engl.) eingesehen werden.

Für die Web-Integration ist PHP eine ausgezeichnete Schnittstelle. PHP
gibt es bei http://www.php.net

Desweiteren bietet sich die Perl-Schnittstelle mit CGI.pm
oder mod_perl auch an.

=== Hat PostgreSQL eine grafische Benutzerschnittstelle? ===

Es gibt eine große Anzahl von GUI-Programmen für PostgreSQL - sowohl
kommerziell als auch Open-Source. [http://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools Eine englische Liste befindet sich hier.]

== Administrative Fragen ==

=== Wie installiere ich PostgreSQL woanders als in /usr/local/pgsql? ===

Bei der Ausführung von configure die Option --prefix mit dem Zielverzeichnis angeben.

=== Wie regle ich Zugriffe von anderen Rechnern? ===

PostgreSQL ist standardmäßig so eingestellt, dass Verbindungen nur vom
lokalen Rechner über Unix Domain Sockets bzw. TCP/IP möglich sind.
Verbindungen von anderen Rechnern werden erst dann ermöglicht, wenn
Sie in der Datei postgresql.conf die Einstellung listen_addresses
anpassen, in der Datei $PGDATA/pg_hba.conf host-basierte
Authentifizierung einschalten und den Server neu starten.

=== Wie kann ich eine bessere Performanz erreichen? ===

Es gibt drei große Bereiche, in denen Performanzverbesserungen erzielt
werden können:

==== Abfrageoptimierung ====
Die Modifizierung von Abfragen kann eine bessere Performanz erzielen:

* [http://www.postgresql.org/docs/current/interactive/indexes.html Erstellung von Indexen, einschliesslich partieller Indexe sowie Expressionsindexe]
* Einsatz von COPY anstelle multipler INSERT-Anweisungen
* Gruppierung von mehreren Abfragen innerhalb einer Transaktion, um Aufwand beim Abschluss von Transaktionen einzusparen
* Einsatz von CLUSTER beim Holen von einer großen Anzahl von Datenreihen aus einem Index
* Einsatz von LIMIT, um eine Untermenge der Abfragenergebnisse zurückzuliefern
* [http://www.postgresql.org/docs/current/interactive/sql-prepare.html Einsatz von vorbereiteten Befehlen (prepared queries)]
* Einsatz von ANALYZE, um die Datenbankstatistik für den Abfragenplaner aktuell zu halten
* [http://www.postgresql.org/docs/current/static/routine-vacuuming.html Regelmäßiger Einsatz von VACUUM bzw. pg_autovacuum (autovacuum ist seit Version 8.3 standardmäßig aktiviert)]
* Bei großen Datenveränderungen die Löschung von Indexen

==== Server-Konfiguration ====
Einige Einstellungen in der Datei postgresql.conf wirken sich auf die Performanz aus. Das Handbuch enthält unter http://www.postgresql.org/docs/current/static/runtime-config.html eine komplette Auflistung.

Kommentare zu den jeweiligen Einstellungen gibt es unter http://www.varlena.com/varlena/GeneralBits/Tidbitsannotated_conf_e.html und http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html.

==== Hardware-Auswahl ====
Die Auswirkung von Hardware auf Performanz wird unter http://momjian.us/main/writings/pgsql/hw_performance/index.html und http://www.powerpostgresql.com/PerfList/ erläutert.

=== Welche Debugging-Funktionen sind für PostgreSQL verfügbar? ===

Unter den Optionen für die Server-Konfigurierung gibt es zahlreiche
log_*-Variablen, die die Ausgabe von Abfrage- und Prozessstatistiken
ermöglichen. Diese können für Debugging-Zwecke sowie Performanz-Tests
sehr nützlich sein.

=== Ich bekomme die Meldung "Sorry, too many clients", wenn ich eine Verbindung aufzubauen versuche. Warum? ===

Ihr System hat die maximal zulässige Anzahl von Datenbankverbindungen
erreicht (Voreinstellung 100). Sie müssen die maximale Anzahl der
gleichzeitig ausführbaren Backend-Prozesse hochsetzen, indem Sie in
postgresql.conf den Wert max_connections ändern und den Server
neustarten.

=== Wie wird PostgreSQL aktualisiert? ===

Allgemeine Informationen zur Aktualisierung von PostgreSQL gibt es auf
der Seite http://www.postgresql.org/support/versioning. Detaillierte
technische Informationen gibt es auf der Seite
http://www.postgresql.org/docs/current/static/install-upgrading.html

=== Kommt PostgreSQL mit den Anpassungen der Sommerzeit in verschiedenen Ländern klar? ===

Für die Berücksichtigung der Sommerzeit verwendet PostgreSQL Seit dem Release 8.0 die weiterverbreitete tzdata-Datenbank (auch bekannt als "zoneinfo database" oder "[http://www.twinsun.com/tz/tz-link.htm| Olzen timezone database]".

Jedes Update von PostgreSQL beinhaltet die aktuellen tzdata Dateien, daher sollte es reichen die Minor-Updates der eingesetzten Major Version im Auge zu behalten.

Unter der Vorraussetzung dass das Betriebssystem diese Dateien schon in einer stets aktuellen Version vorbehält, ist es üblich, dass man diese Dateien verwendet. PostgreSQL bietet dazu eine compile-option an.

=== Welche Hardware eignet sich für den Betrieb mit PostgreSQL? ===

PostgreSQL läuft auf fast jeder Hardware-Kombination. Im PC-Bereich
gibt es allerdings sehr große Abweichungen in der Qualität. Für einen
Arbeitsplatz- oder Entwicklungsrechner mag dies nicht so bedeutend
sein, im Server-Betrieb jedoch lohnt sich auf jeden Fall die
Investition in teurere Bestandteile (Stichwörter ECC-Speicher, SCSI,
Hauptplatinen und Netzteile von namhaften Herstellern). Nutzen Sie
unsere Mailing-Listen, um Hardware-Optionen zu diskutieren.

== Fragen zum Betrieb ==

=== Wie wähle ich per SELECT-Anweisung nur die ersten paar Zeilen bzw. eine beliebige Zeile in einer Abfrage aus? ===

Wenn Sie bei der Ausführung der Abfrage die Anzahl der anzufordenden
Reihen bereits kennen, nutzen Sie LIMIT. Wenn die ORDER BY- Anweisung
mit einem Index verwendet wird, ist es möglich, dass die gesamte
Abfrage nicht ausgeführt werden muss. Wenn Sie die Anzahl der der
anzufordenden Reihen nicht kennen, verwenden Sie einen Cursor und
FETCH.

Um eine beliebige Zeile auszuwählen, nutzen Sie ORDER BY random():
SELECT spalte
FROM tabelle
ORDER BY random()
LIMIT 1

=== Wie finde ich heraus, welche Tabellen, Indexe, Datenbanken oder Benutzer in der Datenbank definiert sind? Wie bekomme ich die von psql verwendeten Abfragen? ===

In psql zeigt der Befehl \dt eine Liste der Datenbanktabellen. Weitere
psql-Befehle lassen sich mit \? anzeigen. Sie können sich die Datei
pgsql/src/bin/psql/describe.c mit dem Quellcode für psql ansehen. Sie
enthält die SQL-Abfragen, die die Backslash-Kommandos (\) ausführen.
Sie können psql auch mit der -E Option starten. Danach gibt psql die
Abfragen aus, die es bei der Ausführung der Befehle benutzt. Außerdem
biete PostgreSQL ein SQL-kompatibles INFORMATION SCHEMA, das
Metainformation über die Datenbank zur Verfügung stellt.

Mit psql -l können Sie alle Datenbanken anzeigen lassen.

Die Datei pgsql/src/tutorial/syscat.source enthält außerdem viele
SELECT- Abfragen, mit deren Hilfe man Information über die
Systemtabellen erhalten kann.

=== Wie ändere ich den Datentyp einer Spalte? ===

Ab Version 8.0 kann der Datentyp einer Spalte mit ALTER TABLE ALTER
COLUMN TYPE geändert werden, sofern der neue Datentyp die Werte des
alten Datentype aufnehmen kann.

Bei früheren Versionen gehen Sie wie folgt vor:
BEGIN;
ALTER TABLE tabelle ADD COLUMN neue_spalte neuer_datentyp;
UPDATE tabelle SET neue_spalte = CAST(alte_spalte AS neuer_datentyp);
ALTER TABLE tabelle DROP COLUMN alte_spalte;
COMMIT;

Um den Speicherplatz freizugeben, der von der gelöschten Spalte
verwendet wurde, führen Sie VACUUM FULL aus.

=== Was ist die Maximalgröße für eine Zeile, eine Tabelle, eine Datenbank? ===

Es bestehen folgende Obergrenzen:
Maximale Größe eine Datenbank? unbeschränkt (es existieren
Datenbanken mit 32 TB)
Maximale Größe einer Tabelle? 32 TB
Maximale Größe einer Zeile? 400 GB
Maximale Größe einer Spalte? 1 GB
Maximale Anzahl von Zeilen in einer Tabelle?
unbeschränkt
Maximale Anzahl von Spalten in einer Tabelle?
250-1600 je nach Spaltentyp
Maximale Anzahl von Indexen für eine Tabelle?
unbeschränkt

Selbstverständlich sind dies theoretische Werte, die oft durch die
verfügbaren Platten- und Speicherressourcen beschränkt werden. Extreme
Größen können zu Leistungseinbußen führen.

Die maximale Tabellengröße von 32 TB benötigt keine
Large-File-Unterstützung im Betriebssystem. Große Tabellen werden in
Dateien mit einer Größe von je 1 GB aufgeteilt, wodurch etwaige
dateisystem-bedingte Beschränkungen nicht relevant sind.

Die maximale Tabellengröße und die maximale Anzahl von Spalten können
vervierfacht werden, indem man die Default-Blockgröße auf 32 KB
heraufsetzt. Die Tabellengröße kann auch durch Tabellenpartitionierung
vergrößert werden.

Eine Einschränkung ist, dass Indexe nur auf Spalten erstellt werden
können, die bis etwa 2.000 Zeichen groß sind. Um auf größere Spalten
eine UNIQUE-Constraint setzen zu können, nutzen Sie einen funktionalen
Index mit dem MD5-Hash-Wert der Spalte. Um innerhalb einer großen, mit
Text belegten Spalte suchen zu können, verwenden Sie einen
Volltext-Index.

=== Wieviel Plattenplatz wird benötigt, um die Daten aus einer typischen Textdatei abzuspeichern? ===

Eine PostgreSQL-Datenbank kann beim Abspeichern einer einfachen
Textdatei bis zu fünfmal mehr Platz gegenüber der eigentlichen Größe
der Datei beanspruchen.

Betrachten wir eine Datei mit 100.000 Zeilen mit einem Integer und
einer Textbeschreibung pro Zeile. Gehen wir davon aus, dass die
durchschnittliche Länge der Textbeschreibung 20 Byte beträgt. Die
einfache Datei würde 2,8 MB groß sein. Die Größe der
PostgreSQL-Datenbankdatei, die diese Daten enthält, liegt ungefähr bei
5,2 MB:
24 Bytes: jeder Zeilenkopf (ungefähr)
+24 Bytes: ein Integer-Feld und ein Textfeld
+ 4 Bytes: Zeiger auf der Datenseite auf den Tupel
-----------------------------------------------
52 Bytes pro Zeile

Die Größe einer Datenseite in PostgreSQL beträgt 8192 Bytes (8 KB),
also:
8192 Bytes pro Seite
--------------------- = 146 Zeilen pro Seite (abgerundet)
52 Bytes pro Zeile

100.000 Datenzeilen
------------------------ = 685 Datenbankseiten (aufgerundet)
158 Zeilen pro Seite

633 Datenbankseiten * 8192 Bytes pro Seite = 5,185,536 bytes (5,2 MB)

Indexe beanspruchen nicht so viel Platz. Da sie jedoch die Daten
beinhalten, die sie indizieren, können auch sie sehr groß werden.

NULL-Werte werden als Bitmaps gespeichert, wodurch sie sehr wenig
Platz in Anspruch nehmen.

=== Meine Abfragen sind langsam oder benutzen die Indexe nicht. Warum? ===

Indexe werden nicht automatisch bei jeder Abfrage verwendet. Indexe
werden nur dann verwendet, wenn die abzufragende Tabelle eine
bestimmte Größe übersteigt, und die Abfrage nur eine kleine
Prozentzahl der Tabellenzeilen abfragt. Der Grund hierfür ist der,
dass die durch einen Index verursachten Festplattenzugriffe manchmal
länger dauern würden als ein einfaches Auslesen aller Tabellenzeilen
(sequentieller Scan).

Um festzustellen, ob ein Index verwendet werden soll, braucht
PostgreSQL Statistiken über die Tabelle. Diese Statistiken werden
durch die Anweisungen VACUUM ANALYZE bzw. ANALYZE berechnet. Anhand
der Statistiken kennt der Abfragenoptimierer die Anzahl der
Tabellenzeilen und kann besser entscheiden, ob Indexe verwendet werden
sollen. Statistiken sind auch bei der Ermittlung der optimalen
JOIN-Reihenfolgen und -Methoden wertvoll. Daher sollten diese
regelmässig durchgeführt werden, da sich der Inhalt einer Tabelle ja
auch verändert.

Indexe werden normalerweise nicht in ORDER BY-Abfrage oder in JOINs
verwendet. Ein sequentieller Scan mit anschließendem explizitem
Sortiervorgang ist normalerweise schneller als ein Index-Scan einer
großen Tabelle. Jedoch wird bei einer Abfrage, in der LIMIT zusammen
mit ORDER BY verwendet wird, oftmals ein Index verwendet, da nur ein
kleiner Abschnitt der Tabelle zurückgeliefert wird.

Sollte es danach aussehen, also ob der Optimierer irrtümlich einen
sequentiellen Scan ausführt, führen Sie SET enable_seqscan TO 'off'
aus und prüfen Sie, ob die Indexabfrage dadurch scheller geworden ist.

Bei der Nutzung von Wildcard-Operatoren wie LIKE oder ~, können Indexe
nur unter bestimmten Umständen verwendet werden:

* Das Suchmuster muss sich an Anfang des Strings befinden, d.h.:
** LIKE-Suchmuster dürfen nicht mit % anfangen;
** ~ (reguläre Ausdrücke) müssen mit ^ anfangen.
* Das Suchmuster darf nicht mit einer Zeichenklasse (z.B. [a-e]) beginnen.
* Suchmuster, die Gross- und Kleinschreibung nicht berücksichtigen (z.B. ILIKE bzw. ~*), verwenden keine Indexe. Stattdessen können funktionale Indexe verwendet werden, die im Punkt 4.8 beschrieben werden.
* Die Standard-Locale "C" muss während der Datenbank-Initialisierung mit initdb verwendet worden sein, da andere locales den nächstgrößten Wert nicht ermitteln können. Es ist allerdings möglich, einen besonderen text_pattern_ops-Index für solche Fälle zu erstellen.

In Versionen vor 8.0 werden Indexe oft nicht benutzt, wenn die
jeweiligen Datentypen nicht genau übereinstimmen. Dies gilt besonders
für Indexe auf Spalten mit den Datentypen INT2, INT8 und NUMERIC

=== Auf welche Weise kann ich sehen, wie der Abfrage-Optimierer meine Abfrage auswertet? ===

Eine ausführliche Erklärung zu diesem Thema findet sich in der [http://www.postgresql.org/docs/current/static/sql-explain.html EXPLAIN] Dokumentation.

=== Wie änder ich das Sortierverhalten von textähnlichen Daten? ===
PostgreSQL sortiert Daten anhand dem bei initdb gesetzten Locale. (Ab 8.4 wird es es möglich sein pro Datenbank ein eigenes Locale zu definieren)

Entspricht das Sortierverhalten nicht dem gewünschten muss man die Locale ändern. Die meisten Locales, außer "C", sortieren anhand der Reihenfolge des entsprechenden Wörterbuches. Das Locale "C" ignoriert jegliche Punktuation und Zwischenraum.

=== Wie verfahre ich bei der Suche mit regulären Ausdrücken und bei einer Suche, bei der Groß- und Kleinschreibweisen ignoriert werden? Wie verwende ich einen Index bei solchen Suchabfragen? ===

Der Operator ~ wendet einen regulären Ausdruck an und ~* wendet ihn
an, ohne die Groß- und Kleinschreibung zu beachten. Ebenso beachtet
LIKE die Groß- und Kleinschreibung, und ILIKE nicht.

Gleichheitsvergleiche, die Groß- und Kleinschreibung ignorieren,
werden in der Regel so ausgedruckt:
SELECT *
FROM tabelle
WHERE LOWER(spalte) = 'abc'

Hier wird kein normaler Index benutzt. Legt man hingegen einen
funktionalen Index an, so wird er auf jeden Fall verwendet:
CREATE INDEX tabelle_index ON tabelle (LOWER(spalte))

Falls der obige Index als einen UNIQUE-Index angelegt wird, können
keine Werte in die Spalte eingefügt werden, die sich nur durch ihre
Groß- und Kleinschreibung unterscheiden. Um Fehler zu vermeiden muß
ein CHECK-Constraint oder ein Trigger eingesetzt werden.

=== Wie ermittle ich in einer Abfrage, ob ein Feld NULL ist? Kann nach der NULL-Belegung sortiert werden? ===

Testen Sie die Spalte mit IS NULL bzw. IS NOT NULL.
SELECT
*
FROM
tabelle
WHERE
spalte IS NULL

Beim konkatenieren mit einen NULL-Wert wir das Ergebnis auch NULL. Um dies zu verhindern verwenden Sie am besten [http://www.postgresql.org/docs/current/static/functions-conditional.html| COALESCE()]
SELECT
COALESCE(col1, '') || COALESCE(col2, '')
FROM tab;

Um die Spalte danach zu sortieren, ob sie mit NULL belegt ist oder nicht, verwenden Sie die Bedingungen IS NULL bzw. IS NOT NULL in der ORDER BY-Klausel. Da Bedingungen, die wahr sind, höher als das Gegenteil sortiert werden, bewirkt die folgende Abfrage, dass die NULL-Spalten zuerst gelistet werden:
SELECT
*
FROM
tabelle
ORDER BY
(spalte IS NOT NULL)

Ab PostreSQL 8.3 und höher, ist es möglich das standardisierte NULLS FIRST/NULLS LAST zu verwenden um die Position der NULL-Werte im Ergebnis zu bestimmen. (bei FIRST stehen diese zu erst, bei LAST am Ende)
SELECT
*
FROM
tab
ORDER BY
col NULLS FIRST;

=== Was ist der Unterschied zwischen den verschiedenen CHAR-Typen? ===
{| border="1"
!Typ
!interner Name
!Bemerkungen
|-
|VARCHAR(n)
|varchar
|die Größe legt die Maximallänge fest; kein Auffüllen mit Leerzeichen
|-
|CHAR(n)
|bpchar
|mit Leerzeichen gefüllt bis zur angegebenen Länge
|-
|TEXT
|text
|keine obere Grenze für die Länge
|-
|BYTEA
|bytea
|Bytearray mit variabler Länge (auch für '\0'-Bytes geeignet)
|-
|"char" (with the quotes)
|char
|ein Zeichen
|}

Der interne Name kommt vor allem in den Systemkatalogen und in manchen
Fehlermeldungen vor.

Die ersten vier Typen sind "varlena"-Typen (d.h. die ersten vier Bytes
geben die Länge an, gefolgt von den Daten). Daher ist der tatsächlich
belegte Platz immer etwas mehr als die deklarierte Feldgröße.
Allerdings wird unter Umständen auf diese Datentypen Datenkompression
durch das TOAST- Verfahren angewendet, womit der tatsächlich belegte
Platz auch geringer als erwartet ausfallen kann.

Für die Speicherung von Zeichenketten variabler Länge empfiehlt sich
VARCHAR(n). Die maximale Länge eines VARCHAR(n)-Felds wird bei der
Tabellendefinition festgelegt. TEXT setzt keine Längengrenze,
allerdings gibt es eine systembedingte Obergrenze von 1 GB.

CHAR(n) ist geeignet für die Speicherung von Zeichenketten, die alle
die gleiche Länge haben. Bitte beachten Sie, dass CHAR(n) automatisch
Zeichenketten bis zur definierten Feldlänge mit Leerzeichen ausfüllt,
während bei VARCHAR(n) nur die tatsächlich eingegebene Zeichenkette
gespeichert wird.

BYTEA ist für binäre Daten, besonders für Werte, die NULL-Bytes haben.

Alle der hier erwähnten Typen weisen ähnliche Performanzeigenschaften
auf.

=== Wie erzeuge ich ein serielles Feld mit automatischer Erhöhung des Wert? ===

PostgreSQL bietet einen SERIAL-Datentyp. Dies ist zwar kein richtiger Datentyp. Es ist die Kurzform für das Erstellen einer Spalte vom Typ Integer, die von einer Sequenz befüllt wird.

Zum Beispiel:
CREATE TABLE person (
id SERIAL,
name TEXT
)

wird automatisch in:
CREATE SEQUENCE person_id_seq;
CREATE TABLE person (
id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
name TEXT
);

umgewandelt.

Die automatisch generierte Sequenz besitzt immer folgenden Namen:
''tabellederspalte''-''namederspalte''_seq

Die Man-Page zu CREATE SEQUENCE beinhaltet mehr Informationen zu Sequenzen.

Es gibt auch einen Typ BIGSERIAL, dieser unterscheidet sich aber nur darin dass die Spalte den Typ BIGINTEGER bekommt. BIGSERIAL sollte verwendet werden wenn es zu erwarten ist, dass mehr als 2 Milliarden Sequenz-Werte verwendet werden.

=== Wie bekomme ich den Wert einer SERIAL-Sequenz? ===

Eine Möglichkeit wäre, mit der nextval()-Funktion den nächsten SERIAL-Wert von dem Sequenzobjekt vor der Auszuführung einer INSERT-Anweisung anzufordern und ihn dann explizit in die INSERT-Anweisung einzubinden. Anhand der Beispieltabelle in 4.11.1 könnte dieser Vorgang in einer Pseudosprache so aussehen:

new_id = output of execute("SELECT nextval('person_id_seq')");
execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");

Danach stünde der neue Wert in der Variablen new_id für die Verwendung in weiteren Abfragen zur Verfügung, zum Beispiel als Fremdschlüssel zur Tabelle 'person'). Bitte beachten Sie, dass der Name des automatisch erstellten SEQUENCE-Objektes folgenden Name hat: «table»_«serialcolumn»_seq wobei 'table' und 'serialcolumn' die Namen
der jeweils betreffenden Tabelle / Spalte darstellen.

Als weitere Möglichkeit können Sie nach einer INSERT-Anweisung den automatisch eingefügten SERIAL-Wert mit der currval()-Funktion zurückgeben lassen:

execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
new_id = output of execute("SELECT currval('person_id_seq')");

Die einfachste Möglichkeit ist es RETURNING zu verwenden. Ein einfaches Beispiel sähe so aus:
INSERT INTO person (name) VALUES ('Blaise Pascal') RETURNING id;

=== Führt currval() zu einer Race-Condition mit anderen Nutzern? ===

Nein. currval() liefert einen Wert zurück, der von Ihrer
Datenbank-Session bestimmt wird, und der anderen Sessionen nicht zur
Verfügung steht.

=== Warum werden die Sequenzwerte nach einem Transaktionsabbruch nicht zurückgesetzt? Warum gibt es Lücken in der Nummerierung meiner Sequenz-/SERIAL-Spalte? ===

Um die gleichzeitige Abarbeitung von Transaktionen zu verbessern,
werden Sequenzen gerade nicht für andere Transaktionen gesperrt,
sondern die Sequenznummern werden den laufenden Transaktionen sofort
zugeteilt. Lücken in der Sequenznummerierung werden durch abgebrochene
Transaktionen verursacht.

=== Was ist ein OID? ===

Jede Zeile, die in PostgreSQL erzeugt wird, bekommt eine eindeutige OID, sofern die Tabelle nicht mit der Option WITHOUT OIDS angelegt wurde. OIDs sind automatisch zugewiesene 4-Byte-Integer, die innerhalb der gesamten Datenbank einmalig sind. Allerdings laufen sie bei einem Wert von ungefähr 4 Milliarden über. PostgreSQL verwendet OIDs, um
seine interne Systemtabellen zu verbinden.

Um einmalige Idenfikatoren in Datentabellen zu erstellen, wird allerdings empfohlen, statt OIDs Werte zu verwenden, die von SERIAL-Sequenzen erzeugt werden. SERIAL-Sequenzen sind innerhalb einer Tabelle einmalig und daher weniger anfällig für Überläufe. Außerdem können 8-Byte-Sequenzwerte mit BIGSERIAL (SERIAL8) erzeugt werden.

=== Was ist ein CTID? ===

CTIDs werden benutzt, um bestimmte physikalische Zeilen durch Block und Offset Werte zu identifizieren. CTIDs verändern sich, sobald Zeilen verändert oder zurückgeladen werden. Sie werden in Indexeinträgen benutzt um auf die physikalischen Zeilen zu zeigen.

=== Wieso bekomme ich einen Fehler: "ERROR: Memory exhausted in AllocSetAlloc()"? ===

Wahrscheinlich gibt es keinen virtuellen Speicher mehr in Ihrem System
oder Ihr Kernel hat niedrige Höchstgrenzen für bestimmte Ressourcen.
Probieren Sie vor dem Start von postmaster folgendes:
ulimit -d 262144
limit datasize 256m

Je nach benutzter Shell wird nur einer dieser Befehle erfolgreich
ausgeführt werden. Auf jedem Fall wird die Grenze des Datensegments
für Prozesse erhöht werden und eventuell die erfolgreiche Ausführung
der Abfrage ermöglichen. Falls Sie ein Problem mit dem SQL-Client
haben, weil das Backend zu viele Daten zurückliefert, versuchen Sie
dies vor dem Start des SQL-Clients.

=== Wie kann ich feststellen, welche PostgreSQL-Version bei mir läuft? ===

Geben Sie in psql SELECT VERSION(); ein.

=== Wie kann ich eine Spalte erstellen, deren Default-Wert immer die aktuelle Uhrzeit enthalten soll? ===

Dazu verwenden Sie CURRENT_TIMESTAMP:
CREATE TABLE test (x INT, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

=== Wie führe ich eine OUTER JOIN durch? ===

PostgreSQL unterstützt OUTER JOINs nach dem SQL- Standardsyntax. Hier
zwei Beispiele:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 ON (t1.spalte = t2.spalte)

bzw.:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 USING (spalte)

Diese identischen Abfragen verknüpfen tabelle_1 mit tabelle_2 über die
Spalte 'spalte' und geben außerdem alle unverknüpften Zeilen in
tabelle_1 (diejenigen, die keine Entsprechung in tabelle_2 haben)
zurück. Ein RIGHT JOIN würde hingegen alle unverknüpften Zeilen in
tabelle_2 hinzufügen und ein FULL JOIN würde alle verknüpften Zeilen
sowie jeweils alle unverknüpften Zeilen aus den beiden Tabellen
zurückliefern. Die Angabe von OUTER ist nicht zwingend und kann in
LEFT, RIGHT und FULL-Verknüpfungen weggelassen werden. Normale
Verknüpfungen sind INNER JOINs.

=== Wie kann ich Abfragen über mehrere Datenbanken hinweg ausführen? ===

Es gibt keinen Weg, innerhalb einer Abfrage auf mehr als eine
Datenbank zuzugreifen. Da PostgreSQL datenbank-spezifische
Systemkataloge lädt, ist eine datenbankübergreifende Abfrage nicht
möglich.

contrib/dblink ist eine Erweiterung, die datenbankübergreifende
Abfragen über Funktionsaufrufe ermöglicht.

=== Wie kann ich mehrere Zeilen bzw. Spalten von einer Funktion zurückgeben lassen? ===

Funktionen können mehrere Zeilen und Spalten zurückgeben, vgl.:
http://www.postgresql.org/docs/techdocs.17.

=== Warum bekomme ich eine Fehlermeldung wie "relation with OID ##### does not exist" wenn ich temporäre Tabellen in PL/PgSQL-Funktionen benutze? ===

In PostgreSQL-Versionen vor 8.3 verarbeitet PL/PgSQL Funktionen in
einer Cache. Dies hat eine unangenehme Nebenwirkung, nämlich dass wenn
eine PL/PgSQL-Funktion auf eine temporäre Tabelle zugreift, und diese
Tabelle anschließend gelöscht bzw. neu erstellt wird, die Funktion
fehlschlagen wird, da die gecachten Funktionsinhalte noch auf die alte
temporäre Tabelle zeigen. Die Lösung für diese Probleme besteht darin,
in der PL/PgSQL- Funktion mittels EXECUTE auf temporäre Tabellen
zuzugreifen. Dies bewirkt, dass bei jedem Funktionsruf die betreffende
Abfrage neu geparst wird.

Dieses Problem taucht in PostgreSQL 8.3 und späteren Versionen nicht
mehr auf.

=== Welche Replikationslösungen gibt es? ===

Der Begriff "replikation" umfasst mehrere verschiedene Technologien,
jede mit eigenen Vor- und Nachteilen. [http://www.postgresql.org/docs/8.3/static/high-availability.html| Die Dokumentation enthält eine gute Einführung in das Thema Replikation]

Mit "Master/slave"-Replikation werden Änderungen in einer
Hauptdatenbank durchgeführt und an "Sklaven" verteilt, die im
Nur-Lese-Modus arbeiten. Die populärste Lösung für PostgreSQL ist
Slony-I.

"Multi-master replication" ermöglicht sowohl lesende als auch
schreibende Zugriffe über mehrere Datenbank-Server hinweg. Allerdings
hat diese Art von Replikation eine negative Auswirkung auf die
Performanz durch die Notwendigkeit, Änderungen zwischen Servern zu
synchronisieren. Pgcluster ist die populärste freie Lösung für
PostgreSQL.

Es gibt auch einige kommerzielle und hardware-basierte
Replikationslösungen für verschiedene Arten der Replikation.

=== Warum werden die Tabellen- und Spaltennamen in meiner Abfrage nicht erkannt? Warum werden Großbuchstaben umgewandelt? ===

Die häufigste Ursache ist die Verwendung von Gänsefüßchen bei der
Anlegung von Tabellen, z.B.:
CREATE TABLE "Tabelle"
("SPALTE1" INT)

Dadurch werden Tabellen- und Spaltennamen (sog. Identifikatoren) in
genau der Schreibweise gespeichert (vgl. Dokumentation), was dazu
führt, dass man sie danach immer in Gänsefüßchen angeben muss. Im
obigen Beispiel muss man also immer etwa SELECT * FROM "Tabelle"
verwenden. Um dieses Problem zu vermeiden, müssen Sie immer eines der
folgenden Punkte beachten:

* bei der Tabellenanlegung keine Gänsefüßchen verwenden;
* in Identifikatoren nur Kleinschreibung verwenden;
* immer Identifikatoren mit Gänsefüßchen versehen

== Anmerkungen des Übersetzers ==

Die englische Vorlage dieser FAQ wird ständig überarbeitet. Daher
liegt die Übersetzung nicht immer auf dem aktuellsten Stand.

Die aktuellste Version der deutschen Übersetzung befindet sich immer
unter http://sql-info.de/de/postgresql/FAQ_german.html. Diese
"Arbeitsversion" enthält eventuell Änderungen, die noch nicht auf der
PostgreSQL-Website eingebunden worden sind.

Über Verbesserungshinweise und Korrekturvorschläge sowie
Verständnisfragen zum Inhalt der FAQ freue ich mich. Ich nehme auch
allgemeine Fragen zu PostgreSQL gerne entgegen, verweise jedoch auf
die Mailing-Listen als schnelle und zuverlässige Anlaufstellen.

[[Category:FAQ]]

FAQ/de

2011-12-06T18:40:07Z

Mastermind: more markup fixes

{{Languages}}

== Allgemeine Fragen ==

=== Was ist PostgreSQL? Wie wird es ausgesprochen? ===

Die (englische) Aussprache ist "Post-Gres-Q-L". Im allgemeinen
Sprachgebrauch hat sich die Kurzform "Postgres" auch durchgesetzt.
(Für diejenigen, die es interessiert: eine MP3-Datei mit der
amerikanischen Aussprache befindet sich hier:
http://www.postgresql.org/files/postgresql.mp3

PostgreSQL ist ein objektrelationales Datenbanksystem, das die Vorzüge
von kommerziellen Datenbanksystemen mit zukunftsweisenden Innovationen
kombiniert. PostgreSQL ist freie Software und dessen kompletter
Quellcode ist öffentlich verfügbar.

Die PostgreSQL-Entwicklung wird von einem Team von meist freiwilligen
Entwicklern durchgeführt. Dieses Team ist für die Gesamtentwicklung
von PostgreSQL verantwortlich. Es handelt sich um ein
Gemeinschaftsprojekt, das nicht von einer bestimmten Firma
kontrolliert wird. Lesen Sie die Entwickler-FAQ:
http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn Sie an einer
Mitarbeit interessiert sind.

=== Wer kontrolliert PostgreSQL? ===

Falls Sie nach dem Namen eines etwaigen Inhabers bzw. nach einem
allmächtigen Zentralkommittee suchen - sparen Sie sich die Mühe, sowas
existiert gar nicht. Es gibt zwar das "Core Committee" sowie
Entwickler, die CVS-Schreibberechtigung haben, jedoch haben diese
Gruppen eher nur eine administrative Rolle. Das Projekt wird durch die
Community gesteuert, die aus den Entwicklern sowie natürlich auch den
Nutzern besteht - jeder kann daran teilnehmen. (Lesen Sie die
Entwickler-FAQ: http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn
Sie an der PostgreSQL-Entwicklung teilnehmen möchten).

=== Welchem Copyright unterliegt PostgreSQL? ===

PostgreSQL wird unter der klassischen BSD-Lizenz herausgegeben. Im
Grunde genommen erlaubt diese den Nutzern, beliebig mit dem Code
umzugehen, auch der Weiterverkauf von Binärversionen ohne Quellcode
ist erlaubt. Die einzige Einschränkung besteht darin, dass PostgreSQL
auf keinen Fall für etwaige Probleme mit der Software haftet. Außerdem
muß der Copyright- Text in allen Kopien der Software enthalten sein.
Dies ist der Originaltext der BSD-Lizenz:

PostgreSQL Data Base Management System

Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group
Portions Copyright (c) 1994-6 Regents of the University of California

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose, without fee, and without a written
agreement is hereby granted, provided that the above copyright notice
and this paragraph and the following two paragraphs appear in all
copies.

IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY
FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES,
INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND
ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE
PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF
CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT,
UPDATES, ENHANCEMENTS, OR MODIFICATIONS.

Es gilt die Copyright-Klausel im Original!

=== Auf welchen Plattformen läuft PostgreSQL? ===

Normalerweise kann PostgreSQL auf jeder modernen UNIX-kompatiblen
Plattform eingesetzt werden. Diejenigen Plattformen, die bei der
jeweiligen Versionsfreigabe getestet wurden, sind in den
Installationsanleitungen aufgelistet.

PostgreSQL läuft auch auf Microsoft NT-basierten Betriebssystemen wie
Windows 2000 SP4, XP und Server 2003. Ein vorgefertigtes
Installationspaket kann von http://pgfoundry.org/projects/pginstaller
heruntergeladen werden. DOS-basierte Windows-Versionen (Win95, Win98,
WinMe) können PostgreSQL nur mit Hilfe der Cygwin-Umgebung ausführen.

=== Woher bekomme ich PostgreSQL? ===

Per Web-Browser hier: http://www.postgresql.org/ftp/ und per FTP hier:
ftp://ftp.postgresql.org/pub/.

=== Was ist die neueste Version von PostgreSQL? ===

Die neueste Version von PostgreSQL kann auf der [http://www.postgresql.org/ Website] eingesehen werden.

Die Freigabe einer neuen Hauptversion erfolgt in der Regel jährlich, kleinere Korrekturversionen alle paar Monaten. Die kleineren Updates werden "Minor"-Updates, die großen jährlich erscheinenden "Major"-Updates genannt. "Minor"-Update erscheinen in der Regel gleichzeitig für alle unterstützten "Major"-Versionen. [http://www.postgresql.org/support/versioning Falls Sie dieses Thema interessiert sollten Sie hier weiterlesen.]

=== Wo bekomme ich Support für PostgreSQL? ===

Die PostgreSQL-Community bietet Unterstützung per Mailing-Liste. Die
Web-Seite http://www.postgresql.org/community/lists/ bietet einen
Überblick. Die Listen general und bugs bieten einen guten Einstieg.

Eine deutschsprachige Mailing-Liste gibt es hier:
http://archives.postgresql.org/pgsql-de-allgemein/.

Der wichtigsten IRC-Channel ist #postgresql auf Freenode
(irc.freenode.net). Unter UNIX/Linux können Sie mit z.B. irc -c
'#postgresql' "$USER" irc.freenode.net. daran teilnehmen. Auf Freenode
gibt es folgende Channels:
* #postgresql-es (spanisch)
* #postgresqlfr (französischen)
* #postgresql-br (brasilianischen)

Es gibt außerdem einen PostgreSQL-Channel bei EFNet.

Eine Liste von Unternehmen, die Support für PostgreSQL auf kommerzieller Basis leisten, kann unter http://www.postgresql.org/support/professional_support eingesehen werden.

=== Wie kann ich einen Fehlerbericht abgeben? ===

Nutzen Sie das Formular unter
http://www.postgresql.org/support/submitbug. Schauen Sie aber vorher
unter ftp://ftp.postgresql.org/pub/ nach, ob es mittlerweile eine
neuere PostgreSQL-Version gibt, in der der Fehler behoben wurde.

Bugs, die über das Formular bzw. eine der Mailing-Listen
bekanntgegeben wurden, erhalten typischerweise einer der folgenden
Reaktionen:

* es ist kein Bug, der Grund wird benannt
* es ist ein bereits bekannter Bug, der bereits auf der TODO-Liste aufgenommen wurde
* der Bug wurde in der aktuellen Version behoben
* der Bug wurde bereits behoben, befindet sich aber noch nicht in einer offiziell veröffentlichten Version
* es wird um eingehendere Informationen gebeten, z.B.:
** Betriebssystem
** PostgreSQL-Version
** reproduzierbares Fallbeispiel
** Debugging-Information
** Debugger-Backtrace-Ausgabe
* der Bug ist neu. Folgendes könnte passieren:
** ein Patch wird erstellt und in der nächsten Version eingebaut
** der Bug kann nicht sofort behoben werden und wird auf die TODO-Liste gesetzt

=== Wie erfahre ich von bekannten Bugs oder fehlenden Features? ===

PostgreSQL unterstützt eine erweiterte Teilmenge von SQL:2003. Siehe
unsere TODO-Liste unter http://www.postgresql.org/docs/faqs.TODO.html
für eine Auflistung der bekannten Bugs, fehlenden Features und
zukünftigen Pläne.

Eine Anfrage nach einem neuen Feature führt normalerweise zu einer der
folgenden Antworten:

* das Feature ist bereits auf der TODO-Liste
* das Feature ist nicht wünschenswert, weil:
** es vorhandene Funktionalität dupliziert, welche bereits dem SQL-Standard folgt
** es würde die Komplexität der Code-Basis erhöhen, ohne nennenswerte Vorteile zu bringen
** es wäre unsicher bzw. unzuverlässig
* das neue Feature wird der TODO-Liste hinzugefügt

PostgreSQL verwendet kein Bugtracking-System, da es sich als effizienter erwiesen hat, E-Mails direkt zu beantworten und die TODO-Liste aktuell zu halten. In der Praxis werden Bugs sehr schnell beseitigt, und diejenigen Bugs, die Auswirkungen auf eine große Anzahl von Nutzern haben, werden meist kurzfristig korrigiert. Der einzige Überblick über alle Änderungen, Verbesserungen und Korrekturen in einer PostgreSQL-Version befindet sich in den CVS-Log-Meldungen. Auch die Release-Notes listen nicht jede Änderung in der Software auf.

=== Welche Dokumentation ist für PostgreSQL verfügbar? ===

PostgreSQL bietet umfangreiche Dokumentation, darunter ein großes
Handbuch, man-Pages und einige kleine Testprogramme. Siehe das /doc-
Verzeichnis. Ausserdem sind alle Handbücher online unter
http://www.postgresql.org/docs/ verfügbar.

Zwei Bücher zu PostgreSQL sind online verfügbar unter
http://www.postgresql.org/docs/books/awbook.html und
http://www.commandprompt.com/ppbook/ .

Eine Liste lieferbarer PostgreSQL-Bücher befindet sich unter
http://www.postgresql.org/docs/books Diverse technische Artikel
befinden sich unter http://www.postgresql.org/docs/techdocs .

psql hat einige nützliche \d-Befehle, um Informationen über Typen,
Operatoren, Funktionen, Aggregate, usw. zu zeigen.

Die PostgreSQL-Website enthält noch mehr Dokumentation.

=== Wie kann ich SQL lernen? ===

Die oben erwähnten PostgreSQL-spezifische Bücher bieten einen guten
Einstieg. Viele PostgreSQL-Anwender mögen "The Practical SQL Handbook"
(Bowman et al., Addison Wesley). Andere dagegen mögen "The Complete
Reference SQL" (Groff et al., McGraw-Hill).

Es gibt ausserdem einige nützliche Online-Tutorials:

* http://www.intermedia.net/support/sql/sqltut.shtm
* http://sqlcourse.com
* http://www.w3schools.com/sql/default.asp
* http://mysite.verizon.net/Graeme_Birchall/id1.html

=== Wie kann ich im Entwicklerteam mitarbeiten? ===

Lesen Sie in der Entwickler-FAQ unter
[[Developer_FAQ | Developer FAQ]] nach.

=== Wie läuft PostgreSQL im Vergleich zu anderen Datenbanksystemen? ===

Es gibt verschiedene Methoden, Software zu messen: Eigenschaften,
Performanz, Zuverlässigkeit, Support und Preis.

==== Eigenschaften ====

PostgreSQL besitzt die meisten Eigenschaften - wie
Transaktionen, Unterabfragen (Subqueries), Trigger, Views,
referenzielle Integrität bei Fremdschlüsseln und verfeinertes
Locking - die bei großen kommerziellen DBMS vorhanden sind. Es
bietet außerdem einige anderen Eigenschaften, die diese nicht
immer haben, wie benutzerbestimmte Typen, Vererbung, Regeln,
und die Multi-Versionen-Steuerung zum Verringern
konkurrierender Locks.

==== Performanz ====
Die Performanz von PostgreSQL ist mit der von kommerziellen und
anderen Open-Source-Datenbanken vergleichbar. In manchen
Bereichen ist es schneller, in anderen langsamer. In der Regel
beträgt der Unterschied +/-10%.

==== Zuverlässigkeit ====
Es ist selbstredend, dass ein DBMS wertlos ist, wenn es nicht
zuverlässig arbeitet. Daher bemühen wir uns, nur streng
geprüften und beständigen Code freizugeben, der nur ein Minimum
an Programmfehlern aufweist. Jede Freigabe hat mindestens einen
Monat Betatest-Phase hinter sich, und unsere Freigabehistorie
beweist, dass wir stabile und solide Versionen freigeben, die
im Produktionsbetrieb genutzt werden können. Wir glauben, dass
wir im Vergleich mit anderer Datenbanksoftware vorteilhaft
dastehen.

==== Support ====
Unsere Mailinglisten bieten die Möglichkeit, gemeinsam mit
einer großen Gruppe von Entwicklern und Benutzern mögliche
Probleme zu lösen. Wir können nicht immer eine Fehlerbehebung
garantieren, kommerzielle DBMS tun dies aber auch nicht. Der
direkte Kontakt zur Entwickler- und Benutzergemeinschaft und
der Zugriff auf die Handbücher und den Quellcode ermöglicht
einen im Vergleich zu anderen DBMS höherwertigeren Support. Es
gibt jedoch auch Anbieter von kommerziellen Support-Leistungen
(siehe FAQ-Punkt 1.7).

==== Preis ====
PostgreSQL ist frei verfügbar, sowohl für die kommerzielle wie
auch für die nicht-kommerzielle Nutzung. Sie können den
PostgreSQL-Code ohne Einschränkungen (außer denjenigen, die in
der oben angegebene BSD-artigen Lizenz erwähnt werden) in Ihr
Produkt integrieren.

=== Kann PostgreSQL eingebettet (embedded) werden? ===
PostgreSQL basiert auf einer Server/Client-Architektur, diese benötigt separate Prozesse für jeden Klient und Server, hinzukommen auch noch weitere "Helfer-Prozesse" (z. B. für autovacuum und stats-collector). Zwar können einige "embedded-Architekturen" diese Anforderungen erfüllen, aber wenn der Datenbank-Prozess innerhalb des Applikations-Prozesses laufen muss, kann PostgreSQL nicht verwendet werden. Dazu sollte man leichtere Datenbanken nehmen.

=== Wie kann ich mich von einer Maillingliste abmelden? Wie verhindere ich es, dass ich doppelte E-Mails bekomme? ===
Majordomo ermöglicht es sich von allen Maillinglisten an- und abzumelden, ggf. müssen Sie sich zuerst ihr Majordomo-Passwort zuschicken lassen.
[http://mail.postgresql.org/mj/mj_wwwusr PostgreSQLs Majordomo erreichen Sie hier.]

Die PostgreSQL-Maillinglisten sind so konfiguriert, dass Antworten an den ursprünglichen Autor und an die Maillingliste verschickt werden. Somit soll erreicht werden dass Benutzer immer schnellstmöglichst eine Antwort erhalten können. Diese Einstellungen können Sie auch über die Konfiguration von Majordomo ändern, ändern Sie dafür die Einstellung für ''eliminatecc''. Sie können auch einstellen dass Sie selbst keine Antwort auf Ihre eigenen E-Mails bekommen, ändern sie dafür die Einstellung für ''selfcopy''.
[http://mail.postgresql.org/mj/mj_wwwusr PostgreSQLs Majordomo erreichen Sie hier.]

== Fragen zu Benutzerprogrammen ==

=== Welche Schnittstellen gibt es für PostgreSQL? ===

Die PostgreSQL-Installation stellt nur Schnittstellen für C und
Embedded C bereit. Alle weitere Schnittstellen sind unabhängige
Projekte, die einzeln heruntergeladen werden werden müssen. Diese
Trennung ermöglicht individuelle Entwickler-Teams und
Entwicklungszyklen für die jeweiligen Projekte.

Einige Programmiersprachen wie PHP haben eine PostgreSQL-
Schnittstelle bereits eingebaut. Schnittstellen für Sprachen wie Perl,
TCL, Python und viele anderen sind unter http://gborg.postgresql.org
im Bereich Drivers/Interfaces verfügbar sowie per Internet-Suche.

=== Wie kann man PostgreSQL in einer Website nutzen? ===

Eine nette Einführung zu datenbank-gestützten Webseiten kann unter
http://www.webreview.com (engl.) eingesehen werden.

Für die Web-Integration ist PHP eine ausgezeichnete Schnittstelle. PHP
gibt es bei http://www.php.net

Desweiteren bietet sich die Perl-Schnittstelle mit CGI.pm
oder mod_perl auch an.

=== Hat PostgreSQL eine grafische Benutzerschnittstelle? ===

Es gibt eine große Anzahl von GUI-Programmen für PostgreSQL - sowohl
kommerziell als auch Open-Source. [http://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools| Eine englische Liste befindet sich hier.]

== Administrative Fragen ==

=== Wie installiere ich PostgreSQL woanders als in /usr/local/pgsql? ===

Bei der Ausführung von configure die Option --prefix mit dem Zielverzeichnis angeben.

=== Wie regle ich Zugriffe von anderen Rechnern? ===

PostgreSQL ist standardmäßig so eingestellt, dass Verbindungen nur vom
lokalen Rechner über Unix Domain Sockets bzw. TCP/IP möglich sind.
Verbindungen von anderen Rechnern werden erst dann ermöglicht, wenn
Sie in der Datei postgresql.conf die Einstellung listen_addresses
anpassen, in der Datei $PGDATA/pg_hba.conf host-basierte
Authentifizierung einschalten und den Server neu starten.

=== Wie kann ich eine bessere Performanz erreichen? ===

Es gibt drei große Bereiche, in denen Performanzverbesserungen erzielt
werden können:

==== Abfrageoptimierung ====
Die Modifizierung von Abfragen kann eine bessere Performanz erzielen:

* [http://www.postgresql.org/docs/current/interactive/indexes.html Erstellung von Indexen, einschliesslich partieller Indexe sowie Expressionsindexe]
* Einsatz von COPY anstelle multipler INSERT-Anweisungen
* Gruppierung von mehreren Abfragen innerhalb einer Transaktion, um Aufwand beim Abschluss von Transaktionen einzusparen
* Einsatz von CLUSTER beim Holen von einer großen Anzahl von Datenreihen aus einem Index
* Einsatz von LIMIT, um eine Untermenge der Abfragenergebnisse zurückzuliefern
* [http://www.postgresql.org/docs/current/interactive/sql-prepare.html Einsatz von vorbereiteten Befehlen (prepared queries)]
* Einsatz von ANALYZE, um die Datenbankstatistik für den Abfragenplaner aktuell zu halten
* [http://www.postgresql.org/docs/current/static/routine-vacuuming.html Regelmäßiger Einsatz von VACUUM bzw. pg_autovacuum (autovacuum ist seit Version 8.3 standardmäßig aktiviert)]
* Bei großen Datenveränderungen die Löschung von Indexen

==== Server-Konfiguration ====
Einige Einstellungen in der Datei postgresql.conf wirken sich auf die Performanz aus. Das Handbuch enthält unter http://www.postgresql.org/docs/current/static/runtime-config.html eine komplette Auflistung.

Kommentare zu den jeweiligen Einstellungen gibt es unter http://www.varlena.com/varlena/GeneralBits/Tidbitsannotated_conf_e.html und http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html.

==== Hardware-Auswahl ====
Die Auswirkung von Hardware auf Performanz wird unter http://momjian.us/main/writings/pgsql/hw_performance/index.html und http://www.powerpostgresql.com/PerfList/ erläutert.

=== Welche Debugging-Funktionen sind für PostgreSQL verfügbar? ===

Unter den Optionen für die Server-Konfigurierung gibt es zahlreiche
log_*-Variablen, die die Ausgabe von Abfrage- und Prozessstatistiken
ermöglichen. Diese können für Debugging-Zwecke sowie Performanz-Tests
sehr nützlich sein.

=== Ich bekomme die Meldung "Sorry, too many clients", wenn ich eine Verbindung aufzubauen versuche. Warum? ===

Ihr System hat die maximal zulässige Anzahl von Datenbankverbindungen
erreicht (Voreinstellung 100). Sie müssen die maximale Anzahl der
gleichzeitig ausführbaren Backend-Prozesse hochsetzen, indem Sie in
postgresql.conf den Wert max_connections ändern und den Server
neustarten.

=== Wie wird PostgreSQL aktualisiert? ===

Allgemeine Informationen zur Aktualisierung von PostgreSQL gibt es auf
der Seite http://www.postgresql.org/support/versioning. Detaillierte
technische Informationen gibt es auf der Seite
http://www.postgresql.org/docs/current/static/install-upgrading.html

=== Kommt PostgreSQL mit den Anpassungen der Sommerzeit in verschiedenen Ländern klar? ===

Für die Berücksichtigung der Sommerzeit verwendet PostgreSQL Seit dem Release 8.0 die weiterverbreitete tzdata-Datenbank (auch bekannt als "zoneinfo database" oder "[http://www.twinsun.com/tz/tz-link.htm| Olzen timezone database]".

Jedes Update von PostgreSQL beinhaltet die aktuellen tzdata Dateien, daher sollte es reichen die Minor-Updates der eingesetzten Major Version im Auge zu behalten.

Unter der Vorraussetzung dass das Betriebssystem diese Dateien schon in einer stets aktuellen Version vorbehält, ist es üblich, dass man diese Dateien verwendet. PostgreSQL bietet dazu eine compile-option an.

=== Welche Hardware eignet sich für den Betrieb mit PostgreSQL? ===

PostgreSQL läuft auf fast jeder Hardware-Kombination. Im PC-Bereich
gibt es allerdings sehr große Abweichungen in der Qualität. Für einen
Arbeitsplatz- oder Entwicklungsrechner mag dies nicht so bedeutend
sein, im Server-Betrieb jedoch lohnt sich auf jeden Fall die
Investition in teurere Bestandteile (Stichwörter ECC-Speicher, SCSI,
Hauptplatinen und Netzteile von namhaften Herstellern). Nutzen Sie
unsere Mailing-Listen, um Hardware-Optionen zu diskutieren.

== Fragen zum Betrieb ==

=== Wie wähle ich per SELECT-Anweisung nur die ersten paar Zeilen bzw. eine beliebige Zeile in einer Abfrage aus? ===

Wenn Sie bei der Ausführung der Abfrage die Anzahl der anzufordenden
Reihen bereits kennen, nutzen Sie LIMIT. Wenn die ORDER BY- Anweisung
mit einem Index verwendet wird, ist es möglich, dass die gesamte
Abfrage nicht ausgeführt werden muss. Wenn Sie die Anzahl der der
anzufordenden Reihen nicht kennen, verwenden Sie einen Cursor und
FETCH.

Um eine beliebige Zeile auszuwählen, nutzen Sie ORDER BY random():
SELECT spalte
FROM tabelle
ORDER BY random()
LIMIT 1

=== Wie finde ich heraus, welche Tabellen, Indexe, Datenbanken oder Benutzer in der Datenbank definiert sind? Wie bekomme ich die von psql verwendeten Abfragen? ===

In psql zeigt der Befehl \dt eine Liste der Datenbanktabellen. Weitere
psql-Befehle lassen sich mit \? anzeigen. Sie können sich die Datei
pgsql/src/bin/psql/describe.c mit dem Quellcode für psql ansehen. Sie
enthält die SQL-Abfragen, die die Backslash-Kommandos (\) ausführen.
Sie können psql auch mit der -E Option starten. Danach gibt psql die
Abfragen aus, die es bei der Ausführung der Befehle benutzt. Außerdem
biete PostgreSQL ein SQL-kompatibles INFORMATION SCHEMA, das
Metainformation über die Datenbank zur Verfügung stellt.

Mit psql -l können Sie alle Datenbanken anzeigen lassen.

Die Datei pgsql/src/tutorial/syscat.source enthält außerdem viele
SELECT- Abfragen, mit deren Hilfe man Information über die
Systemtabellen erhalten kann.

=== Wie ändere ich den Datentyp einer Spalte? ===

Ab Version 8.0 kann der Datentyp einer Spalte mit ALTER TABLE ALTER
COLUMN TYPE geändert werden, sofern der neue Datentyp die Werte des
alten Datentype aufnehmen kann.

Bei früheren Versionen gehen Sie wie folgt vor:
BEGIN;
ALTER TABLE tabelle ADD COLUMN neue_spalte neuer_datentyp;
UPDATE tabelle SET neue_spalte = CAST(alte_spalte AS neuer_datentyp);
ALTER TABLE tabelle DROP COLUMN alte_spalte;
COMMIT;

Um den Speicherplatz freizugeben, der von der gelöschten Spalte
verwendet wurde, führen Sie VACUUM FULL aus.

=== Was ist die Maximalgröße für eine Zeile, eine Tabelle, eine Datenbank? ===

Es bestehen folgende Obergrenzen:
Maximale Größe eine Datenbank? unbeschränkt (es existieren
Datenbanken mit 32 TB)
Maximale Größe einer Tabelle? 32 TB
Maximale Größe einer Zeile? 400 GB
Maximale Größe einer Spalte? 1 GB
Maximale Anzahl von Zeilen in einer Tabelle?
unbeschränkt
Maximale Anzahl von Spalten in einer Tabelle?
250-1600 je nach Spaltentyp
Maximale Anzahl von Indexen für eine Tabelle?
unbeschränkt

Selbstverständlich sind dies theoretische Werte, die oft durch die
verfügbaren Platten- und Speicherressourcen beschränkt werden. Extreme
Größen können zu Leistungseinbußen führen.

Die maximale Tabellengröße von 32 TB benötigt keine
Large-File-Unterstützung im Betriebssystem. Große Tabellen werden in
Dateien mit einer Größe von je 1 GB aufgeteilt, wodurch etwaige
dateisystem-bedingte Beschränkungen nicht relevant sind.

Die maximale Tabellengröße und die maximale Anzahl von Spalten können
vervierfacht werden, indem man die Default-Blockgröße auf 32 KB
heraufsetzt. Die Tabellengröße kann auch durch Tabellenpartitionierung
vergrößert werden.

Eine Einschränkung ist, dass Indexe nur auf Spalten erstellt werden
können, die bis etwa 2.000 Zeichen groß sind. Um auf größere Spalten
eine UNIQUE-Constraint setzen zu können, nutzen Sie einen funktionalen
Index mit dem MD5-Hash-Wert der Spalte. Um innerhalb einer großen, mit
Text belegten Spalte suchen zu können, verwenden Sie einen
Volltext-Index.

=== Wieviel Plattenplatz wird benötigt, um die Daten aus einer typischen Textdatei abzuspeichern? ===

Eine PostgreSQL-Datenbank kann beim Abspeichern einer einfachen
Textdatei bis zu fünfmal mehr Platz gegenüber der eigentlichen Größe
der Datei beanspruchen.

Betrachten wir eine Datei mit 100.000 Zeilen mit einem Integer und
einer Textbeschreibung pro Zeile. Gehen wir davon aus, dass die
durchschnittliche Länge der Textbeschreibung 20 Byte beträgt. Die
einfache Datei würde 2,8 MB groß sein. Die Größe der
PostgreSQL-Datenbankdatei, die diese Daten enthält, liegt ungefähr bei
5,2 MB:
24 Bytes: jeder Zeilenkopf (ungefähr)
+24 Bytes: ein Integer-Feld und ein Textfeld
+ 4 Bytes: Zeiger auf der Datenseite auf den Tupel
-----------------------------------------------
52 Bytes pro Zeile

Die Größe einer Datenseite in PostgreSQL beträgt 8192 Bytes (8 KB),
also:
8192 Bytes pro Seite
--------------------- = 146 Zeilen pro Seite (abgerundet)
52 Bytes pro Zeile

100.000 Datenzeilen
------------------------ = 685 Datenbankseiten (aufgerundet)
158 Zeilen pro Seite

633 Datenbankseiten * 8192 Bytes pro Seite = 5,185,536 bytes (5,2 MB)

Indexe beanspruchen nicht so viel Platz. Da sie jedoch die Daten
beinhalten, die sie indizieren, können auch sie sehr groß werden.

NULL-Werte werden als Bitmaps gespeichert, wodurch sie sehr wenig
Platz in Anspruch nehmen.

=== Meine Abfragen sind langsam oder benutzen die Indexe nicht. Warum? ===

Indexe werden nicht automatisch bei jeder Abfrage verwendet. Indexe
werden nur dann verwendet, wenn die abzufragende Tabelle eine
bestimmte Größe übersteigt, und die Abfrage nur eine kleine
Prozentzahl der Tabellenzeilen abfragt. Der Grund hierfür ist der,
dass die durch einen Index verursachten Festplattenzugriffe manchmal
länger dauern würden als ein einfaches Auslesen aller Tabellenzeilen
(sequentieller Scan).

Um festzustellen, ob ein Index verwendet werden soll, braucht
PostgreSQL Statistiken über die Tabelle. Diese Statistiken werden
durch die Anweisungen VACUUM ANALYZE bzw. ANALYZE berechnet. Anhand
der Statistiken kennt der Abfragenoptimierer die Anzahl der
Tabellenzeilen und kann besser entscheiden, ob Indexe verwendet werden
sollen. Statistiken sind auch bei der Ermittlung der optimalen
JOIN-Reihenfolgen und -Methoden wertvoll. Daher sollten diese
regelmässig durchgeführt werden, da sich der Inhalt einer Tabelle ja
auch verändert.

Indexe werden normalerweise nicht in ORDER BY-Abfrage oder in JOINs
verwendet. Ein sequentieller Scan mit anschließendem explizitem
Sortiervorgang ist normalerweise schneller als ein Index-Scan einer
großen Tabelle. Jedoch wird bei einer Abfrage, in der LIMIT zusammen
mit ORDER BY verwendet wird, oftmals ein Index verwendet, da nur ein
kleiner Abschnitt der Tabelle zurückgeliefert wird.

Sollte es danach aussehen, also ob der Optimierer irrtümlich einen
sequentiellen Scan ausführt, führen Sie SET enable_seqscan TO 'off'
aus und prüfen Sie, ob die Indexabfrage dadurch scheller geworden ist.

Bei der Nutzung von Wildcard-Operatoren wie LIKE oder ~, können Indexe
nur unter bestimmten Umständen verwendet werden:

* Das Suchmuster muss sich an Anfang des Strings befinden, d.h.:
** LIKE-Suchmuster dürfen nicht mit % anfangen;
** ~ (reguläre Ausdrücke) müssen mit ^ anfangen.
* Das Suchmuster darf nicht mit einer Zeichenklasse (z.B. [a-e]) beginnen.
* Suchmuster, die Gross- und Kleinschreibung nicht berücksichtigen (z.B. ILIKE bzw. ~*), verwenden keine Indexe. Stattdessen können funktionale Indexe verwendet werden, die im Punkt 4.8 beschrieben werden.
* Die Standard-Locale "C" muss während der Datenbank-Initialisierung mit initdb verwendet worden sein, da andere locales den nächstgrößten Wert nicht ermitteln können. Es ist allerdings möglich, einen besonderen text_pattern_ops-Index für solche Fälle zu erstellen.

In Versionen vor 8.0 werden Indexe oft nicht benutzt, wenn die
jeweiligen Datentypen nicht genau übereinstimmen. Dies gilt besonders
für Indexe auf Spalten mit den Datentypen INT2, INT8 und NUMERIC

=== Auf welche Weise kann ich sehen, wie der Abfrage-Optimierer meine Abfrage auswertet? ===

Eine ausführliche Erklärung zu diesem Thema findet sich in der [http://www.postgresql.org/docs/current/static/sql-explain.html EXPLAIN] Dokumentation.

=== Wie änder ich das Sortierverhalten von textähnlichen Daten? ===
PostgreSQL sortiert Daten anhand dem bei initdb gesetzten Locale. (Ab 8.4 wird es es möglich sein pro Datenbank ein eigenes Locale zu definieren)

Entspricht das Sortierverhalten nicht dem gewünschten muss man die Locale ändern. Die meisten Locales, außer "C", sortieren anhand der Reihenfolge des entsprechenden Wörterbuches. Das Locale "C" ignoriert jegliche Punktuation und Zwischenraum.

=== Wie verfahre ich bei der Suche mit regulären Ausdrücken und bei einer Suche, bei der Groß- und Kleinschreibweisen ignoriert werden? Wie verwende ich einen Index bei solchen Suchabfragen? ===

Der Operator ~ wendet einen regulären Ausdruck an und ~* wendet ihn
an, ohne die Groß- und Kleinschreibung zu beachten. Ebenso beachtet
LIKE die Groß- und Kleinschreibung, und ILIKE nicht.

Gleichheitsvergleiche, die Groß- und Kleinschreibung ignorieren,
werden in der Regel so ausgedruckt:
SELECT *
FROM tabelle
WHERE LOWER(spalte) = 'abc'

Hier wird kein normaler Index benutzt. Legt man hingegen einen
funktionalen Index an, so wird er auf jeden Fall verwendet:
CREATE INDEX tabelle_index ON tabelle (LOWER(spalte))

Falls der obige Index als einen UNIQUE-Index angelegt wird, können
keine Werte in die Spalte eingefügt werden, die sich nur durch ihre
Groß- und Kleinschreibung unterscheiden. Um Fehler zu vermeiden muß
ein CHECK-Constraint oder ein Trigger eingesetzt werden.

=== Wie ermittle ich in einer Abfrage, ob ein Feld NULL ist? Kann nach der NULL-Belegung sortiert werden? ===

Testen Sie die Spalte mit IS NULL bzw. IS NOT NULL.
SELECT
*
FROM
tabelle
WHERE
spalte IS NULL

Beim konkatenieren mit einen NULL-Wert wir das Ergebnis auch NULL. Um dies zu verhindern verwenden Sie am besten [http://www.postgresql.org/docs/current/static/functions-conditional.html| COALESCE()]
SELECT
COALESCE(col1, '') || COALESCE(col2, '')
FROM tab;

Um die Spalte danach zu sortieren, ob sie mit NULL belegt ist oder nicht, verwenden Sie die Bedingungen IS NULL bzw. IS NOT NULL in der ORDER BY-Klausel. Da Bedingungen, die wahr sind, höher als das Gegenteil sortiert werden, bewirkt die folgende Abfrage, dass die NULL-Spalten zuerst gelistet werden:
SELECT
*
FROM
tabelle
ORDER BY
(spalte IS NOT NULL)

Ab PostreSQL 8.3 und höher, ist es möglich das standardisierte NULLS FIRST/NULLS LAST zu verwenden um die Position der NULL-Werte im Ergebnis zu bestimmen. (bei FIRST stehen diese zu erst, bei LAST am Ende)
SELECT
*
FROM
tab
ORDER BY
col NULLS FIRST;

=== Was ist der Unterschied zwischen den verschiedenen CHAR-Typen? ===
{| border="1"
!Typ
!interner Name
!Bemerkungen
|-
|VARCHAR(n)
|varchar
|die Größe legt die Maximallänge fest; kein Auffüllen mit Leerzeichen
|-
|CHAR(n)
|bpchar
|mit Leerzeichen gefüllt bis zur angegebenen Länge
|-
|TEXT
|text
|keine obere Grenze für die Länge
|-
|BYTEA
|bytea
|Bytearray mit variabler Länge (auch für '\0'-Bytes geeignet)
|-
|"char" (with the quotes)
|char
|ein Zeichen
|}

Der interne Name kommt vor allem in den Systemkatalogen und in manchen
Fehlermeldungen vor.

Die ersten vier Typen sind "varlena"-Typen (d.h. die ersten vier Bytes
geben die Länge an, gefolgt von den Daten). Daher ist der tatsächlich
belegte Platz immer etwas mehr als die deklarierte Feldgröße.
Allerdings wird unter Umständen auf diese Datentypen Datenkompression
durch das TOAST- Verfahren angewendet, womit der tatsächlich belegte
Platz auch geringer als erwartet ausfallen kann.

Für die Speicherung von Zeichenketten variabler Länge empfiehlt sich
VARCHAR(n). Die maximale Länge eines VARCHAR(n)-Felds wird bei der
Tabellendefinition festgelegt. TEXT setzt keine Längengrenze,
allerdings gibt es eine systembedingte Obergrenze von 1 GB.

CHAR(n) ist geeignet für die Speicherung von Zeichenketten, die alle
die gleiche Länge haben. Bitte beachten Sie, dass CHAR(n) automatisch
Zeichenketten bis zur definierten Feldlänge mit Leerzeichen ausfüllt,
während bei VARCHAR(n) nur die tatsächlich eingegebene Zeichenkette
gespeichert wird.

BYTEA ist für binäre Daten, besonders für Werte, die NULL-Bytes haben.

Alle der hier erwähnten Typen weisen ähnliche Performanzeigenschaften
auf.

=== Wie erzeuge ich ein serielles Feld mit automatischer Erhöhung des Wert? ===

PostgreSQL bietet einen SERIAL-Datentyp. Dies ist zwar kein richtiger Datentyp. Es ist die Kurzform für das Erstellen einer Spalte vom Typ Integer, die von einer Sequenz befüllt wird.

Zum Beispiel:
CREATE TABLE person (
id SERIAL,
name TEXT
)

wird automatisch in:
CREATE SEQUENCE person_id_seq;
CREATE TABLE person (
id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
name TEXT
);

umgewandelt.

Die automatisch generierte Sequenz besitzt immer folgenden Namen:
''tabellederspalte''-''namederspalte''_seq

Die Man-Page zu CREATE SEQUENCE beinhaltet mehr Informationen zu Sequenzen.

Es gibt auch einen Typ BIGSERIAL, dieser unterscheidet sich aber nur darin dass die Spalte den Typ BIGINTEGER bekommt. BIGSERIAL sollte verwendet werden wenn es zu erwarten ist, dass mehr als 2 Milliarden Sequenz-Werte verwendet werden.

=== Wie bekomme ich den Wert einer SERIAL-Sequenz? ===

Eine Möglichkeit wäre, mit der nextval()-Funktion den nächsten SERIAL-Wert von dem Sequenzobjekt vor der Auszuführung einer INSERT-Anweisung anzufordern und ihn dann explizit in die INSERT-Anweisung einzubinden. Anhand der Beispieltabelle in 4.11.1 könnte dieser Vorgang in einer Pseudosprache so aussehen:

new_id = output of execute("SELECT nextval('person_id_seq')");
execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");

Danach stünde der neue Wert in der Variablen new_id für die Verwendung in weiteren Abfragen zur Verfügung, zum Beispiel als Fremdschlüssel zur Tabelle 'person'). Bitte beachten Sie, dass der Name des automatisch erstellten SEQUENCE-Objektes folgenden Name hat: «table»_«serialcolumn»_seq wobei 'table' und 'serialcolumn' die Namen
der jeweils betreffenden Tabelle / Spalte darstellen.

Als weitere Möglichkeit können Sie nach einer INSERT-Anweisung den automatisch eingefügten SERIAL-Wert mit der currval()-Funktion zurückgeben lassen:

execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
new_id = output of execute("SELECT currval('person_id_seq')");

Die einfachste Möglichkeit ist es RETURNING zu verwenden. Ein einfaches Beispiel sähe so aus:
INSERT INTO person (name) VALUES ('Blaise Pascal') RETURNING id;

=== Führt currval() zu einer Race-Condition mit anderen Nutzern? ===

Nein. currval() liefert einen Wert zurück, der von Ihrer
Datenbank-Session bestimmt wird, und der anderen Sessionen nicht zur
Verfügung steht.

=== Warum werden die Sequenzwerte nach einem Transaktionsabbruch nicht zurückgesetzt? Warum gibt es Lücken in der Nummerierung meiner Sequenz-/SERIAL-Spalte? ===

Um die gleichzeitige Abarbeitung von Transaktionen zu verbessern,
werden Sequenzen gerade nicht für andere Transaktionen gesperrt,
sondern die Sequenznummern werden den laufenden Transaktionen sofort
zugeteilt. Lücken in der Sequenznummerierung werden durch abgebrochene
Transaktionen verursacht.

=== Was ist ein OID? ===

Jede Zeile, die in PostgreSQL erzeugt wird, bekommt eine eindeutige OID, sofern die Tabelle nicht mit der Option WITHOUT OIDS angelegt wurde. OIDs sind automatisch zugewiesene 4-Byte-Integer, die innerhalb der gesamten Datenbank einmalig sind. Allerdings laufen sie bei einem Wert von ungefähr 4 Milliarden über. PostgreSQL verwendet OIDs, um
seine interne Systemtabellen zu verbinden.

Um einmalige Idenfikatoren in Datentabellen zu erstellen, wird allerdings empfohlen, statt OIDs Werte zu verwenden, die von SERIAL-Sequenzen erzeugt werden. SERIAL-Sequenzen sind innerhalb einer Tabelle einmalig und daher weniger anfällig für Überläufe. Außerdem können 8-Byte-Sequenzwerte mit BIGSERIAL (SERIAL8) erzeugt werden.

=== Was ist ein CTID? ===

CTIDs werden benutzt, um bestimmte physikalische Zeilen durch Block und Offset Werte zu identifizieren. CTIDs verändern sich, sobald Zeilen verändert oder zurückgeladen werden. Sie werden in Indexeinträgen benutzt um auf die physikalischen Zeilen zu zeigen.

=== Wieso bekomme ich einen Fehler: "ERROR: Memory exhausted in AllocSetAlloc()"? ===

Wahrscheinlich gibt es keinen virtuellen Speicher mehr in Ihrem System
oder Ihr Kernel hat niedrige Höchstgrenzen für bestimmte Ressourcen.
Probieren Sie vor dem Start von postmaster folgendes:
ulimit -d 262144
limit datasize 256m

Je nach benutzter Shell wird nur einer dieser Befehle erfolgreich
ausgeführt werden. Auf jedem Fall wird die Grenze des Datensegments
für Prozesse erhöht werden und eventuell die erfolgreiche Ausführung
der Abfrage ermöglichen. Falls Sie ein Problem mit dem SQL-Client
haben, weil das Backend zu viele Daten zurückliefert, versuchen Sie
dies vor dem Start des SQL-Clients.

=== Wie kann ich feststellen, welche PostgreSQL-Version bei mir läuft? ===

Geben Sie in psql SELECT VERSION(); ein.

=== Wie kann ich eine Spalte erstellen, deren Default-Wert immer die aktuelle Uhrzeit enthalten soll? ===

Dazu verwenden Sie CURRENT_TIMESTAMP:
CREATE TABLE test (x INT, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

=== Wie führe ich eine OUTER JOIN durch? ===

PostgreSQL unterstützt OUTER JOINs nach dem SQL- Standardsyntax. Hier
zwei Beispiele:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 ON (t1.spalte = t2.spalte)

bzw.:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 USING (spalte)

Diese identischen Abfragen verknüpfen tabelle_1 mit tabelle_2 über die
Spalte 'spalte' und geben außerdem alle unverknüpften Zeilen in
tabelle_1 (diejenigen, die keine Entsprechung in tabelle_2 haben)
zurück. Ein RIGHT JOIN würde hingegen alle unverknüpften Zeilen in
tabelle_2 hinzufügen und ein FULL JOIN würde alle verknüpften Zeilen
sowie jeweils alle unverknüpften Zeilen aus den beiden Tabellen
zurückliefern. Die Angabe von OUTER ist nicht zwingend und kann in
LEFT, RIGHT und FULL-Verknüpfungen weggelassen werden. Normale
Verknüpfungen sind INNER JOINs.

=== Wie kann ich Abfragen über mehrere Datenbanken hinweg ausführen? ===

Es gibt keinen Weg, innerhalb einer Abfrage auf mehr als eine
Datenbank zuzugreifen. Da PostgreSQL datenbank-spezifische
Systemkataloge lädt, ist eine datenbankübergreifende Abfrage nicht
möglich.

contrib/dblink ist eine Erweiterung, die datenbankübergreifende
Abfragen über Funktionsaufrufe ermöglicht.

=== Wie kann ich mehrere Zeilen bzw. Spalten von einer Funktion zurückgeben lassen? ===

Funktionen können mehrere Zeilen und Spalten zurückgeben, vgl.:
http://www.postgresql.org/docs/techdocs.17.

=== Warum bekomme ich eine Fehlermeldung wie "relation with OID ##### does not exist" wenn ich temporäre Tabellen in PL/PgSQL-Funktionen benutze? ===

In PostgreSQL-Versionen vor 8.3 verarbeitet PL/PgSQL Funktionen in
einer Cache. Dies hat eine unangenehme Nebenwirkung, nämlich dass wenn
eine PL/PgSQL-Funktion auf eine temporäre Tabelle zugreift, und diese
Tabelle anschließend gelöscht bzw. neu erstellt wird, die Funktion
fehlschlagen wird, da die gecachten Funktionsinhalte noch auf die alte
temporäre Tabelle zeigen. Die Lösung für diese Probleme besteht darin,
in der PL/PgSQL- Funktion mittels EXECUTE auf temporäre Tabellen
zuzugreifen. Dies bewirkt, dass bei jedem Funktionsruf die betreffende
Abfrage neu geparst wird.

Dieses Problem taucht in PostgreSQL 8.3 und späteren Versionen nicht
mehr auf.

=== Welche Replikationslösungen gibt es? ===

Der Begriff "replikation" umfasst mehrere verschiedene Technologien,
jede mit eigenen Vor- und Nachteilen. [http://www.postgresql.org/docs/8.3/static/high-availability.html| Die Dokumentation enthält eine gute Einführung in das Thema Replikation]

Mit "Master/slave"-Replikation werden Änderungen in einer
Hauptdatenbank durchgeführt und an "Sklaven" verteilt, die im
Nur-Lese-Modus arbeiten. Die populärste Lösung für PostgreSQL ist
Slony-I.

"Multi-master replication" ermöglicht sowohl lesende als auch
schreibende Zugriffe über mehrere Datenbank-Server hinweg. Allerdings
hat diese Art von Replikation eine negative Auswirkung auf die
Performanz durch die Notwendigkeit, Änderungen zwischen Servern zu
synchronisieren. Pgcluster ist die populärste freie Lösung für
PostgreSQL.

Es gibt auch einige kommerzielle und hardware-basierte
Replikationslösungen für verschiedene Arten der Replikation.

=== Warum werden die Tabellen- und Spaltennamen in meiner Abfrage nicht erkannt? Warum werden Großbuchstaben umgewandelt? ===

Die häufigste Ursache ist die Verwendung von Gänsefüßchen bei der
Anlegung von Tabellen, z.B.:
CREATE TABLE "Tabelle"
("SPALTE1" INT)

Dadurch werden Tabellen- und Spaltennamen (sog. Identifikatoren) in
genau der Schreibweise gespeichert (vgl. Dokumentation), was dazu
führt, dass man sie danach immer in Gänsefüßchen angeben muss. Im
obigen Beispiel muss man also immer etwa SELECT * FROM "Tabelle"
verwenden. Um dieses Problem zu vermeiden, müssen Sie immer eines der
folgenden Punkte beachten:

* bei der Tabellenanlegung keine Gänsefüßchen verwenden;
* in Identifikatoren nur Kleinschreibung verwenden;
* immer Identifikatoren mit Gänsefüßchen versehen

== Anmerkungen des Übersetzers ==

Die englische Vorlage dieser FAQ wird ständig überarbeitet. Daher
liegt die Übersetzung nicht immer auf dem aktuellsten Stand.

Die aktuellste Version der deutschen Übersetzung befindet sich immer
unter http://sql-info.de/de/postgresql/FAQ_german.html. Diese
"Arbeitsversion" enthält eventuell Änderungen, die noch nicht auf der
PostgreSQL-Website eingebunden worden sind.

Über Verbesserungshinweise und Korrekturvorschläge sowie
Verständnisfragen zum Inhalt der FAQ freue ich mich. Ich nehme auch
allgemeine Fragen zu PostgreSQL gerne entgegen, verweise jedoch auf
die Mailing-Listen als schnelle und zuverlässige Anlaufstellen.

[[Category:FAQ]]

FAQ/de

2011-12-06T18:38:43Z

Mastermind: another markup fix

{{Languages}}

== Allgemeine Fragen ==

=== Was ist PostgreSQL? Wie wird es ausgesprochen? ===

Die (englische) Aussprache ist "Post-Gres-Q-L". Im allgemeinen
Sprachgebrauch hat sich die Kurzform "Postgres" auch durchgesetzt.
(Für diejenigen, die es interessiert: eine MP3-Datei mit der
amerikanischen Aussprache befindet sich hier:
http://www.postgresql.org/files/postgresql.mp3

PostgreSQL ist ein objektrelationales Datenbanksystem, das die Vorzüge
von kommerziellen Datenbanksystemen mit zukunftsweisenden Innovationen
kombiniert. PostgreSQL ist freie Software und dessen kompletter
Quellcode ist öffentlich verfügbar.

Die PostgreSQL-Entwicklung wird von einem Team von meist freiwilligen
Entwicklern durchgeführt. Dieses Team ist für die Gesamtentwicklung
von PostgreSQL verantwortlich. Es handelt sich um ein
Gemeinschaftsprojekt, das nicht von einer bestimmten Firma
kontrolliert wird. Lesen Sie die Entwickler-FAQ:
http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn Sie an einer
Mitarbeit interessiert sind.

=== Wer kontrolliert PostgreSQL? ===

Falls Sie nach dem Namen eines etwaigen Inhabers bzw. nach einem
allmächtigen Zentralkommittee suchen - sparen Sie sich die Mühe, sowas
existiert gar nicht. Es gibt zwar das "Core Committee" sowie
Entwickler, die CVS-Schreibberechtigung haben, jedoch haben diese
Gruppen eher nur eine administrative Rolle. Das Projekt wird durch die
Community gesteuert, die aus den Entwicklern sowie natürlich auch den
Nutzern besteht - jeder kann daran teilnehmen. (Lesen Sie die
Entwickler-FAQ: http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn
Sie an der PostgreSQL-Entwicklung teilnehmen möchten).

=== Welchem Copyright unterliegt PostgreSQL? ===

PostgreSQL wird unter der klassischen BSD-Lizenz herausgegeben. Im
Grunde genommen erlaubt diese den Nutzern, beliebig mit dem Code
umzugehen, auch der Weiterverkauf von Binärversionen ohne Quellcode
ist erlaubt. Die einzige Einschränkung besteht darin, dass PostgreSQL
auf keinen Fall für etwaige Probleme mit der Software haftet. Außerdem
muß der Copyright- Text in allen Kopien der Software enthalten sein.
Dies ist der Originaltext der BSD-Lizenz:

PostgreSQL Data Base Management System

Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group
Portions Copyright (c) 1994-6 Regents of the University of California

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose, without fee, and without a written
agreement is hereby granted, provided that the above copyright notice
and this paragraph and the following two paragraphs appear in all
copies.

IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY
FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES,
INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND
ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE
PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF
CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT,
UPDATES, ENHANCEMENTS, OR MODIFICATIONS.

Es gilt die Copyright-Klausel im Original!

=== Auf welchen Plattformen läuft PostgreSQL? ===

Normalerweise kann PostgreSQL auf jeder modernen UNIX-kompatiblen
Plattform eingesetzt werden. Diejenigen Plattformen, die bei der
jeweiligen Versionsfreigabe getestet wurden, sind in den
Installationsanleitungen aufgelistet.

PostgreSQL läuft auch auf Microsoft NT-basierten Betriebssystemen wie
Windows 2000 SP4, XP und Server 2003. Ein vorgefertigtes
Installationspaket kann von http://pgfoundry.org/projects/pginstaller
heruntergeladen werden. DOS-basierte Windows-Versionen (Win95, Win98,
WinMe) können PostgreSQL nur mit Hilfe der Cygwin-Umgebung ausführen.

=== Woher bekomme ich PostgreSQL? ===

Per Web-Browser hier: http://www.postgresql.org/ftp/ und per FTP hier:
ftp://ftp.postgresql.org/pub/.

=== Was ist die neueste Version von PostgreSQL? ===

Die neueste Version von PostgreSQL kann auf der [http://www.postgresql.org/ Website] eingesehen werden.

Die Freigabe einer neuen Hauptversion erfolgt in der Regel jährlich, kleinere Korrekturversionen alle paar Monaten. Die kleineren Updates werden "Minor"-Updates, die großen jährlich erscheinenden "Major"-Updates genannt. "Minor"-Update erscheinen in der Regel gleichzeitig für alle unterstützten "Major"-Versionen. [http://www.postgresql.org/support/versioning Falls Sie dieses Thema interessiert sollten Sie hier weiterlesen.]

=== Wo bekomme ich Support für PostgreSQL? ===

Die PostgreSQL-Community bietet Unterstützung per Mailing-Liste. Die
Web-Seite http://www.postgresql.org/community/lists/ bietet einen
Überblick. Die Listen general und bugs bieten einen guten Einstieg.

Eine deutschsprachige Mailing-Liste gibt es hier:
http://archives.postgresql.org/pgsql-de-allgemein/.

Der wichtigsten IRC-Channel ist #postgresql auf Freenode
(irc.freenode.net). Unter UNIX/Linux können Sie mit z.B. irc -c
'#postgresql' "$USER" irc.freenode.net. daran teilnehmen. Auf Freenode
gibt es folgende Channels:
* #postgresql-es (spanisch)
* #postgresqlfr (französischen)
* #postgresql-br (brasilianischen)

Es gibt außerdem einen PostgreSQL-Channel bei EFNet.

Eine Liste von Unternehmen, die Support für PostgreSQL auf kommerzieller Basis leisten, kann unter http://www.postgresql.org/support/professional_support eingesehen werden.

=== Wie kann ich einen Fehlerbericht abgeben? ===

Nutzen Sie das Formular unter
http://www.postgresql.org/support/submitbug. Schauen Sie aber vorher
unter ftp://ftp.postgresql.org/pub/ nach, ob es mittlerweile eine
neuere PostgreSQL-Version gibt, in der der Fehler behoben wurde.

Bugs, die über das Formular bzw. eine der Mailing-Listen
bekanntgegeben wurden, erhalten typischerweise einer der folgenden
Reaktionen:

* es ist kein Bug, der Grund wird benannt
* es ist ein bereits bekannter Bug, der bereits auf der TODO-Liste aufgenommen wurde
* der Bug wurde in der aktuellen Version behoben
* der Bug wurde bereits behoben, befindet sich aber noch nicht in einer offiziell veröffentlichten Version
* es wird um eingehendere Informationen gebeten, z.B.:
** Betriebssystem
** PostgreSQL-Version
** reproduzierbares Fallbeispiel
** Debugging-Information
** Debugger-Backtrace-Ausgabe
* der Bug ist neu. Folgendes könnte passieren:
** ein Patch wird erstellt und in der nächsten Version eingebaut
** der Bug kann nicht sofort behoben werden und wird auf die TODO-Liste gesetzt

=== Wie erfahre ich von bekannten Bugs oder fehlenden Features? ===

PostgreSQL unterstützt eine erweiterte Teilmenge von SQL:2003. Siehe
unsere TODO-Liste unter http://www.postgresql.org/docs/faqs.TODO.html
für eine Auflistung der bekannten Bugs, fehlenden Features und
zukünftigen Pläne.

Eine Anfrage nach einem neuen Feature führt normalerweise zu einer der
folgenden Antworten:

* das Feature ist bereits auf der TODO-Liste
* das Feature ist nicht wünschenswert, weil:
** es vorhandene Funktionalität dupliziert, welche bereits dem SQL-Standard folgt
** es würde die Komplexität der Code-Basis erhöhen, ohne nennenswerte Vorteile zu bringen
** es wäre unsicher bzw. unzuverlässig
* das neue Feature wird der TODO-Liste hinzugefügt

PostgreSQL verwendet kein Bugtracking-System, da es sich als effizienter erwiesen hat, E-Mails direkt zu beantworten und die TODO-Liste aktuell zu halten. In der Praxis werden Bugs sehr schnell beseitigt, und diejenigen Bugs, die Auswirkungen auf eine große Anzahl von Nutzern haben, werden meist kurzfristig korrigiert. Der einzige Überblick über alle Änderungen, Verbesserungen und Korrekturen in einer PostgreSQL-Version befindet sich in den CVS-Log-Meldungen. Auch die Release-Notes listen nicht jede Änderung in der Software auf.

=== Welche Dokumentation ist für PostgreSQL verfügbar? ===

PostgreSQL bietet umfangreiche Dokumentation, darunter ein großes
Handbuch, man-Pages und einige kleine Testprogramme. Siehe das /doc-
Verzeichnis. Ausserdem sind alle Handbücher online unter
http://www.postgresql.org/docs/ verfügbar.

Zwei Bücher zu PostgreSQL sind online verfügbar unter
http://www.postgresql.org/docs/books/awbook.html und
http://www.commandprompt.com/ppbook/ .

Eine Liste lieferbarer PostgreSQL-Bücher befindet sich unter
http://www.postgresql.org/docs/books Diverse technische Artikel
befinden sich unter http://www.postgresql.org/docs/techdocs .

psql hat einige nützliche \d-Befehle, um Informationen über Typen,
Operatoren, Funktionen, Aggregate, usw. zu zeigen.

Die PostgreSQL-Website enthält noch mehr Dokumentation.

=== Wie kann ich SQL lernen? ===

Die oben erwähnten PostgreSQL-spezifische Bücher bieten einen guten
Einstieg. Viele PostgreSQL-Anwender mögen "The Practical SQL Handbook"
(Bowman et al., Addison Wesley). Andere dagegen mögen "The Complete
Reference SQL" (Groff et al., McGraw-Hill).

Es gibt ausserdem einige nützliche Online-Tutorials:

* http://www.intermedia.net/support/sql/sqltut.shtm
* http://sqlcourse.com
* http://www.w3schools.com/sql/default.asp
* http://mysite.verizon.net/Graeme_Birchall/id1.html

=== Wie kann ich im Entwicklerteam mitarbeiten? ===

Lesen Sie in der Entwickler-FAQ unter
[[Developer_FAQ | Developer FAQ]] nach.

=== Wie läuft PostgreSQL im Vergleich zu anderen Datenbanksystemen? ===

Es gibt verschiedene Methoden, Software zu messen: Eigenschaften,
Performanz, Zuverlässigkeit, Support und Preis.

==== Eigenschaften ====

PostgreSQL besitzt die meisten Eigenschaften - wie
Transaktionen, Unterabfragen (Subqueries), Trigger, Views,
referenzielle Integrität bei Fremdschlüsseln und verfeinertes
Locking - die bei großen kommerziellen DBMS vorhanden sind. Es
bietet außerdem einige anderen Eigenschaften, die diese nicht
immer haben, wie benutzerbestimmte Typen, Vererbung, Regeln,
und die Multi-Versionen-Steuerung zum Verringern
konkurrierender Locks.

==== Performanz ====
Die Performanz von PostgreSQL ist mit der von kommerziellen und
anderen Open-Source-Datenbanken vergleichbar. In manchen
Bereichen ist es schneller, in anderen langsamer. In der Regel
beträgt der Unterschied +/-10%.

==== Zuverlässigkeit ====
Es ist selbstredend, dass ein DBMS wertlos ist, wenn es nicht
zuverlässig arbeitet. Daher bemühen wir uns, nur streng
geprüften und beständigen Code freizugeben, der nur ein Minimum
an Programmfehlern aufweist. Jede Freigabe hat mindestens einen
Monat Betatest-Phase hinter sich, und unsere Freigabehistorie
beweist, dass wir stabile und solide Versionen freigeben, die
im Produktionsbetrieb genutzt werden können. Wir glauben, dass
wir im Vergleich mit anderer Datenbanksoftware vorteilhaft
dastehen.

==== Support ====
Unsere Mailinglisten bieten die Möglichkeit, gemeinsam mit
einer großen Gruppe von Entwicklern und Benutzern mögliche
Probleme zu lösen. Wir können nicht immer eine Fehlerbehebung
garantieren, kommerzielle DBMS tun dies aber auch nicht. Der
direkte Kontakt zur Entwickler- und Benutzergemeinschaft und
der Zugriff auf die Handbücher und den Quellcode ermöglicht
einen im Vergleich zu anderen DBMS höherwertigeren Support. Es
gibt jedoch auch Anbieter von kommerziellen Support-Leistungen
(siehe FAQ-Punkt 1.7).

==== Preis ====
PostgreSQL ist frei verfügbar, sowohl für die kommerzielle wie
auch für die nicht-kommerzielle Nutzung. Sie können den
PostgreSQL-Code ohne Einschränkungen (außer denjenigen, die in
der oben angegebene BSD-artigen Lizenz erwähnt werden) in Ihr
Produkt integrieren.

=== Kann PostgreSQL eingebettet (embedded) werden? ===
PostgreSQL basiert auf einer Server/Client-Architektur, diese benötigt separate Prozesse für jeden Klient und Server, hinzukommen auch noch weitere "Helfer-Prozesse" (z. B. für autovacuum und stats-collector). Zwar können einige "embedded-Architekturen" diese Anforderungen erfüllen, aber wenn der Datenbank-Prozess innerhalb des Applikations-Prozesses laufen muss, kann PostgreSQL nicht verwendet werden. Dazu sollte man leichtere Datenbanken nehmen.

=== Wie kann ich mich von einer Maillingliste abmelden? Wie verhindere ich es, dass ich doppelte E-Mails bekomme? ===
Majordomo ermöglicht es sich von allen Maillinglisten an- und abzumelden, ggf. müssen Sie sich zuerst ihr Majordomo-Passwort zuschicken lassen.
[http://mail.postgresql.org/mj/mj_wwwusr|PostgreSQLs Majordomo erreichen Sie hier.]

Die PostgreSQL-Maillinglisten sind so konfiguriert, dass Antworten an den ursprünglichen Autor und an die Maillingliste verschickt werden. Somit soll erreicht werden dass Benutzer immer schnellstmöglichst eine Antwort erhalten können. Diese Einstellungen können Sie auch über die Konfiguration von Majordomo ändern, ändern Sie dafür die Einstellung für ''eliminatecc''. Sie können auch einstellen dass Sie selbst keine Antwort auf Ihre eigenen E-Mails bekommen, ändern sie dafür die Einstellung für ''selfcopy''.
[http://mail.postgresql.org/mj/mj_wwwusr|PostgreSQLs Majordomo erreichen Sie hier.]

== Fragen zu Benutzerprogrammen ==

=== Welche Schnittstellen gibt es für PostgreSQL? ===

Die PostgreSQL-Installation stellt nur Schnittstellen für C und
Embedded C bereit. Alle weitere Schnittstellen sind unabhängige
Projekte, die einzeln heruntergeladen werden werden müssen. Diese
Trennung ermöglicht individuelle Entwickler-Teams und
Entwicklungszyklen für die jeweiligen Projekte.

Einige Programmiersprachen wie PHP haben eine PostgreSQL-
Schnittstelle bereits eingebaut. Schnittstellen für Sprachen wie Perl,
TCL, Python und viele anderen sind unter http://gborg.postgresql.org
im Bereich Drivers/Interfaces verfügbar sowie per Internet-Suche.

=== Wie kann man PostgreSQL in einer Website nutzen? ===

Eine nette Einführung zu datenbank-gestützten Webseiten kann unter
http://www.webreview.com (engl.) eingesehen werden.

Für die Web-Integration ist PHP eine ausgezeichnete Schnittstelle. PHP
gibt es bei http://www.php.net

Desweiteren bietet sich die Perl-Schnittstelle mit CGI.pm
oder mod_perl auch an.

=== Hat PostgreSQL eine grafische Benutzerschnittstelle? ===

Es gibt eine große Anzahl von GUI-Programmen für PostgreSQL - sowohl
kommerziell als auch Open-Source. [http://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools| Eine englische Liste befindet sich hier.]

== Administrative Fragen ==

=== Wie installiere ich PostgreSQL woanders als in /usr/local/pgsql? ===

Bei der Ausführung von configure die Option --prefix mit dem Zielverzeichnis angeben.

=== Wie regle ich Zugriffe von anderen Rechnern? ===

PostgreSQL ist standardmäßig so eingestellt, dass Verbindungen nur vom
lokalen Rechner über Unix Domain Sockets bzw. TCP/IP möglich sind.
Verbindungen von anderen Rechnern werden erst dann ermöglicht, wenn
Sie in der Datei postgresql.conf die Einstellung listen_addresses
anpassen, in der Datei $PGDATA/pg_hba.conf host-basierte
Authentifizierung einschalten und den Server neu starten.

=== Wie kann ich eine bessere Performanz erreichen? ===

Es gibt drei große Bereiche, in denen Performanzverbesserungen erzielt
werden können:

==== Abfrageoptimierung ====
Die Modifizierung von Abfragen kann eine bessere Performanz erzielen:

* [http://www.postgresql.org/docs/current/interactive/indexes.html Erstellung von Indexen, einschliesslich partieller Indexe sowie Expressionsindexe]
* Einsatz von COPY anstelle multipler INSERT-Anweisungen
* Gruppierung von mehreren Abfragen innerhalb einer Transaktion, um Aufwand beim Abschluss von Transaktionen einzusparen
* Einsatz von CLUSTER beim Holen von einer großen Anzahl von Datenreihen aus einem Index
* Einsatz von LIMIT, um eine Untermenge der Abfragenergebnisse zurückzuliefern
* [http://www.postgresql.org/docs/current/interactive/sql-prepare.html Einsatz von vorbereiteten Befehlen (prepared queries)]
* Einsatz von ANALYZE, um die Datenbankstatistik für den Abfragenplaner aktuell zu halten
* [http://www.postgresql.org/docs/current/static/routine-vacuuming.html Regelmäßiger Einsatz von VACUUM bzw. pg_autovacuum (autovacuum ist seit Version 8.3 standardmäßig aktiviert)]
* Bei großen Datenveränderungen die Löschung von Indexen

==== Server-Konfiguration ====
Einige Einstellungen in der Datei postgresql.conf wirken sich auf die Performanz aus. Das Handbuch enthält unter http://www.postgresql.org/docs/current/static/runtime-config.html eine komplette Auflistung.

Kommentare zu den jeweiligen Einstellungen gibt es unter http://www.varlena.com/varlena/GeneralBits/Tidbitsannotated_conf_e.html und http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html.

==== Hardware-Auswahl ====
Die Auswirkung von Hardware auf Performanz wird unter http://momjian.us/main/writings/pgsql/hw_performance/index.html und http://www.powerpostgresql.com/PerfList/ erläutert.

=== Welche Debugging-Funktionen sind für PostgreSQL verfügbar? ===

Unter den Optionen für die Server-Konfigurierung gibt es zahlreiche
log_*-Variablen, die die Ausgabe von Abfrage- und Prozessstatistiken
ermöglichen. Diese können für Debugging-Zwecke sowie Performanz-Tests
sehr nützlich sein.

=== Ich bekomme die Meldung "Sorry, too many clients", wenn ich eine Verbindung aufzubauen versuche. Warum? ===

Ihr System hat die maximal zulässige Anzahl von Datenbankverbindungen
erreicht (Voreinstellung 100). Sie müssen die maximale Anzahl der
gleichzeitig ausführbaren Backend-Prozesse hochsetzen, indem Sie in
postgresql.conf den Wert max_connections ändern und den Server
neustarten.

=== Wie wird PostgreSQL aktualisiert? ===

Allgemeine Informationen zur Aktualisierung von PostgreSQL gibt es auf
der Seite http://www.postgresql.org/support/versioning. Detaillierte
technische Informationen gibt es auf der Seite
http://www.postgresql.org/docs/current/static/install-upgrading.html

=== Kommt PostgreSQL mit den Anpassungen der Sommerzeit in verschiedenen Ländern klar? ===

Für die Berücksichtigung der Sommerzeit verwendet PostgreSQL Seit dem Release 8.0 die weiterverbreitete tzdata-Datenbank (auch bekannt als "zoneinfo database" oder "[http://www.twinsun.com/tz/tz-link.htm| Olzen timezone database]".

Jedes Update von PostgreSQL beinhaltet die aktuellen tzdata Dateien, daher sollte es reichen die Minor-Updates der eingesetzten Major Version im Auge zu behalten.

Unter der Vorraussetzung dass das Betriebssystem diese Dateien schon in einer stets aktuellen Version vorbehält, ist es üblich, dass man diese Dateien verwendet. PostgreSQL bietet dazu eine compile-option an.

=== Welche Hardware eignet sich für den Betrieb mit PostgreSQL? ===

PostgreSQL läuft auf fast jeder Hardware-Kombination. Im PC-Bereich
gibt es allerdings sehr große Abweichungen in der Qualität. Für einen
Arbeitsplatz- oder Entwicklungsrechner mag dies nicht so bedeutend
sein, im Server-Betrieb jedoch lohnt sich auf jeden Fall die
Investition in teurere Bestandteile (Stichwörter ECC-Speicher, SCSI,
Hauptplatinen und Netzteile von namhaften Herstellern). Nutzen Sie
unsere Mailing-Listen, um Hardware-Optionen zu diskutieren.

== Fragen zum Betrieb ==

=== Wie wähle ich per SELECT-Anweisung nur die ersten paar Zeilen bzw. eine beliebige Zeile in einer Abfrage aus? ===

Wenn Sie bei der Ausführung der Abfrage die Anzahl der anzufordenden
Reihen bereits kennen, nutzen Sie LIMIT. Wenn die ORDER BY- Anweisung
mit einem Index verwendet wird, ist es möglich, dass die gesamte
Abfrage nicht ausgeführt werden muss. Wenn Sie die Anzahl der der
anzufordenden Reihen nicht kennen, verwenden Sie einen Cursor und
FETCH.

Um eine beliebige Zeile auszuwählen, nutzen Sie ORDER BY random():
SELECT spalte
FROM tabelle
ORDER BY random()
LIMIT 1

=== Wie finde ich heraus, welche Tabellen, Indexe, Datenbanken oder Benutzer in der Datenbank definiert sind? Wie bekomme ich die von psql verwendeten Abfragen? ===

In psql zeigt der Befehl \dt eine Liste der Datenbanktabellen. Weitere
psql-Befehle lassen sich mit \? anzeigen. Sie können sich die Datei
pgsql/src/bin/psql/describe.c mit dem Quellcode für psql ansehen. Sie
enthält die SQL-Abfragen, die die Backslash-Kommandos (\) ausführen.
Sie können psql auch mit der -E Option starten. Danach gibt psql die
Abfragen aus, die es bei der Ausführung der Befehle benutzt. Außerdem
biete PostgreSQL ein SQL-kompatibles INFORMATION SCHEMA, das
Metainformation über die Datenbank zur Verfügung stellt.

Mit psql -l können Sie alle Datenbanken anzeigen lassen.

Die Datei pgsql/src/tutorial/syscat.source enthält außerdem viele
SELECT- Abfragen, mit deren Hilfe man Information über die
Systemtabellen erhalten kann.

=== Wie ändere ich den Datentyp einer Spalte? ===

Ab Version 8.0 kann der Datentyp einer Spalte mit ALTER TABLE ALTER
COLUMN TYPE geändert werden, sofern der neue Datentyp die Werte des
alten Datentype aufnehmen kann.

Bei früheren Versionen gehen Sie wie folgt vor:
BEGIN;
ALTER TABLE tabelle ADD COLUMN neue_spalte neuer_datentyp;
UPDATE tabelle SET neue_spalte = CAST(alte_spalte AS neuer_datentyp);
ALTER TABLE tabelle DROP COLUMN alte_spalte;
COMMIT;

Um den Speicherplatz freizugeben, der von der gelöschten Spalte
verwendet wurde, führen Sie VACUUM FULL aus.

=== Was ist die Maximalgröße für eine Zeile, eine Tabelle, eine Datenbank? ===

Es bestehen folgende Obergrenzen:
Maximale Größe eine Datenbank? unbeschränkt (es existieren
Datenbanken mit 32 TB)
Maximale Größe einer Tabelle? 32 TB
Maximale Größe einer Zeile? 400 GB
Maximale Größe einer Spalte? 1 GB
Maximale Anzahl von Zeilen in einer Tabelle?
unbeschränkt
Maximale Anzahl von Spalten in einer Tabelle?
250-1600 je nach Spaltentyp
Maximale Anzahl von Indexen für eine Tabelle?
unbeschränkt

Selbstverständlich sind dies theoretische Werte, die oft durch die
verfügbaren Platten- und Speicherressourcen beschränkt werden. Extreme
Größen können zu Leistungseinbußen führen.

Die maximale Tabellengröße von 32 TB benötigt keine
Large-File-Unterstützung im Betriebssystem. Große Tabellen werden in
Dateien mit einer Größe von je 1 GB aufgeteilt, wodurch etwaige
dateisystem-bedingte Beschränkungen nicht relevant sind.

Die maximale Tabellengröße und die maximale Anzahl von Spalten können
vervierfacht werden, indem man die Default-Blockgröße auf 32 KB
heraufsetzt. Die Tabellengröße kann auch durch Tabellenpartitionierung
vergrößert werden.

Eine Einschränkung ist, dass Indexe nur auf Spalten erstellt werden
können, die bis etwa 2.000 Zeichen groß sind. Um auf größere Spalten
eine UNIQUE-Constraint setzen zu können, nutzen Sie einen funktionalen
Index mit dem MD5-Hash-Wert der Spalte. Um innerhalb einer großen, mit
Text belegten Spalte suchen zu können, verwenden Sie einen
Volltext-Index.

=== Wieviel Plattenplatz wird benötigt, um die Daten aus einer typischen Textdatei abzuspeichern? ===

Eine PostgreSQL-Datenbank kann beim Abspeichern einer einfachen
Textdatei bis zu fünfmal mehr Platz gegenüber der eigentlichen Größe
der Datei beanspruchen.

Betrachten wir eine Datei mit 100.000 Zeilen mit einem Integer und
einer Textbeschreibung pro Zeile. Gehen wir davon aus, dass die
durchschnittliche Länge der Textbeschreibung 20 Byte beträgt. Die
einfache Datei würde 2,8 MB groß sein. Die Größe der
PostgreSQL-Datenbankdatei, die diese Daten enthält, liegt ungefähr bei
5,2 MB:
24 Bytes: jeder Zeilenkopf (ungefähr)
+24 Bytes: ein Integer-Feld und ein Textfeld
+ 4 Bytes: Zeiger auf der Datenseite auf den Tupel
-----------------------------------------------
52 Bytes pro Zeile

Die Größe einer Datenseite in PostgreSQL beträgt 8192 Bytes (8 KB),
also:
8192 Bytes pro Seite
--------------------- = 146 Zeilen pro Seite (abgerundet)
52 Bytes pro Zeile

100.000 Datenzeilen
------------------------ = 685 Datenbankseiten (aufgerundet)
158 Zeilen pro Seite

633 Datenbankseiten * 8192 Bytes pro Seite = 5,185,536 bytes (5,2 MB)

Indexe beanspruchen nicht so viel Platz. Da sie jedoch die Daten
beinhalten, die sie indizieren, können auch sie sehr groß werden.

NULL-Werte werden als Bitmaps gespeichert, wodurch sie sehr wenig
Platz in Anspruch nehmen.

=== Meine Abfragen sind langsam oder benutzen die Indexe nicht. Warum? ===

Indexe werden nicht automatisch bei jeder Abfrage verwendet. Indexe
werden nur dann verwendet, wenn die abzufragende Tabelle eine
bestimmte Größe übersteigt, und die Abfrage nur eine kleine
Prozentzahl der Tabellenzeilen abfragt. Der Grund hierfür ist der,
dass die durch einen Index verursachten Festplattenzugriffe manchmal
länger dauern würden als ein einfaches Auslesen aller Tabellenzeilen
(sequentieller Scan).

Um festzustellen, ob ein Index verwendet werden soll, braucht
PostgreSQL Statistiken über die Tabelle. Diese Statistiken werden
durch die Anweisungen VACUUM ANALYZE bzw. ANALYZE berechnet. Anhand
der Statistiken kennt der Abfragenoptimierer die Anzahl der
Tabellenzeilen und kann besser entscheiden, ob Indexe verwendet werden
sollen. Statistiken sind auch bei der Ermittlung der optimalen
JOIN-Reihenfolgen und -Methoden wertvoll. Daher sollten diese
regelmässig durchgeführt werden, da sich der Inhalt einer Tabelle ja
auch verändert.

Indexe werden normalerweise nicht in ORDER BY-Abfrage oder in JOINs
verwendet. Ein sequentieller Scan mit anschließendem explizitem
Sortiervorgang ist normalerweise schneller als ein Index-Scan einer
großen Tabelle. Jedoch wird bei einer Abfrage, in der LIMIT zusammen
mit ORDER BY verwendet wird, oftmals ein Index verwendet, da nur ein
kleiner Abschnitt der Tabelle zurückgeliefert wird.

Sollte es danach aussehen, also ob der Optimierer irrtümlich einen
sequentiellen Scan ausführt, führen Sie SET enable_seqscan TO 'off'
aus und prüfen Sie, ob die Indexabfrage dadurch scheller geworden ist.

Bei der Nutzung von Wildcard-Operatoren wie LIKE oder ~, können Indexe
nur unter bestimmten Umständen verwendet werden:

* Das Suchmuster muss sich an Anfang des Strings befinden, d.h.:
** LIKE-Suchmuster dürfen nicht mit % anfangen;
** ~ (reguläre Ausdrücke) müssen mit ^ anfangen.
* Das Suchmuster darf nicht mit einer Zeichenklasse (z.B. [a-e]) beginnen.
* Suchmuster, die Gross- und Kleinschreibung nicht berücksichtigen (z.B. ILIKE bzw. ~*), verwenden keine Indexe. Stattdessen können funktionale Indexe verwendet werden, die im Punkt 4.8 beschrieben werden.
* Die Standard-Locale "C" muss während der Datenbank-Initialisierung mit initdb verwendet worden sein, da andere locales den nächstgrößten Wert nicht ermitteln können. Es ist allerdings möglich, einen besonderen text_pattern_ops-Index für solche Fälle zu erstellen.

In Versionen vor 8.0 werden Indexe oft nicht benutzt, wenn die
jeweiligen Datentypen nicht genau übereinstimmen. Dies gilt besonders
für Indexe auf Spalten mit den Datentypen INT2, INT8 und NUMERIC

=== Auf welche Weise kann ich sehen, wie der Abfrage-Optimierer meine Abfrage auswertet? ===

Eine ausführliche Erklärung zu diesem Thema findet sich in der [http://www.postgresql.org/docs/current/static/sql-explain.html EXPLAIN] Dokumentation.

=== Wie änder ich das Sortierverhalten von textähnlichen Daten? ===
PostgreSQL sortiert Daten anhand dem bei initdb gesetzten Locale. (Ab 8.4 wird es es möglich sein pro Datenbank ein eigenes Locale zu definieren)

Entspricht das Sortierverhalten nicht dem gewünschten muss man die Locale ändern. Die meisten Locales, außer "C", sortieren anhand der Reihenfolge des entsprechenden Wörterbuches. Das Locale "C" ignoriert jegliche Punktuation und Zwischenraum.

=== Wie verfahre ich bei der Suche mit regulären Ausdrücken und bei einer Suche, bei der Groß- und Kleinschreibweisen ignoriert werden? Wie verwende ich einen Index bei solchen Suchabfragen? ===

Der Operator ~ wendet einen regulären Ausdruck an und ~* wendet ihn
an, ohne die Groß- und Kleinschreibung zu beachten. Ebenso beachtet
LIKE die Groß- und Kleinschreibung, und ILIKE nicht.

Gleichheitsvergleiche, die Groß- und Kleinschreibung ignorieren,
werden in der Regel so ausgedruckt:
SELECT *
FROM tabelle
WHERE LOWER(spalte) = 'abc'

Hier wird kein normaler Index benutzt. Legt man hingegen einen
funktionalen Index an, so wird er auf jeden Fall verwendet:
CREATE INDEX tabelle_index ON tabelle (LOWER(spalte))

Falls der obige Index als einen UNIQUE-Index angelegt wird, können
keine Werte in die Spalte eingefügt werden, die sich nur durch ihre
Groß- und Kleinschreibung unterscheiden. Um Fehler zu vermeiden muß
ein CHECK-Constraint oder ein Trigger eingesetzt werden.

=== Wie ermittle ich in einer Abfrage, ob ein Feld NULL ist? Kann nach der NULL-Belegung sortiert werden? ===

Testen Sie die Spalte mit IS NULL bzw. IS NOT NULL.
SELECT
*
FROM
tabelle
WHERE
spalte IS NULL

Beim konkatenieren mit einen NULL-Wert wir das Ergebnis auch NULL. Um dies zu verhindern verwenden Sie am besten [http://www.postgresql.org/docs/current/static/functions-conditional.html| COALESCE()]
SELECT
COALESCE(col1, '') || COALESCE(col2, '')
FROM tab;

Um die Spalte danach zu sortieren, ob sie mit NULL belegt ist oder nicht, verwenden Sie die Bedingungen IS NULL bzw. IS NOT NULL in der ORDER BY-Klausel. Da Bedingungen, die wahr sind, höher als das Gegenteil sortiert werden, bewirkt die folgende Abfrage, dass die NULL-Spalten zuerst gelistet werden:
SELECT
*
FROM
tabelle
ORDER BY
(spalte IS NOT NULL)

Ab PostreSQL 8.3 und höher, ist es möglich das standardisierte NULLS FIRST/NULLS LAST zu verwenden um die Position der NULL-Werte im Ergebnis zu bestimmen. (bei FIRST stehen diese zu erst, bei LAST am Ende)
SELECT
*
FROM
tab
ORDER BY
col NULLS FIRST;

=== Was ist der Unterschied zwischen den verschiedenen CHAR-Typen? ===
{| border="1"
!Typ
!interner Name
!Bemerkungen
|-
|VARCHAR(n)
|varchar
|die Größe legt die Maximallänge fest; kein Auffüllen mit Leerzeichen
|-
|CHAR(n)
|bpchar
|mit Leerzeichen gefüllt bis zur angegebenen Länge
|-
|TEXT
|text
|keine obere Grenze für die Länge
|-
|BYTEA
|bytea
|Bytearray mit variabler Länge (auch für '\0'-Bytes geeignet)
|-
|"char" (with the quotes)
|char
|ein Zeichen
|}

Der interne Name kommt vor allem in den Systemkatalogen und in manchen
Fehlermeldungen vor.

Die ersten vier Typen sind "varlena"-Typen (d.h. die ersten vier Bytes
geben die Länge an, gefolgt von den Daten). Daher ist der tatsächlich
belegte Platz immer etwas mehr als die deklarierte Feldgröße.
Allerdings wird unter Umständen auf diese Datentypen Datenkompression
durch das TOAST- Verfahren angewendet, womit der tatsächlich belegte
Platz auch geringer als erwartet ausfallen kann.

Für die Speicherung von Zeichenketten variabler Länge empfiehlt sich
VARCHAR(n). Die maximale Länge eines VARCHAR(n)-Felds wird bei der
Tabellendefinition festgelegt. TEXT setzt keine Längengrenze,
allerdings gibt es eine systembedingte Obergrenze von 1 GB.

CHAR(n) ist geeignet für die Speicherung von Zeichenketten, die alle
die gleiche Länge haben. Bitte beachten Sie, dass CHAR(n) automatisch
Zeichenketten bis zur definierten Feldlänge mit Leerzeichen ausfüllt,
während bei VARCHAR(n) nur die tatsächlich eingegebene Zeichenkette
gespeichert wird.

BYTEA ist für binäre Daten, besonders für Werte, die NULL-Bytes haben.

Alle der hier erwähnten Typen weisen ähnliche Performanzeigenschaften
auf.

=== Wie erzeuge ich ein serielles Feld mit automatischer Erhöhung des Wert? ===

PostgreSQL bietet einen SERIAL-Datentyp. Dies ist zwar kein richtiger Datentyp. Es ist die Kurzform für das Erstellen einer Spalte vom Typ Integer, die von einer Sequenz befüllt wird.

Zum Beispiel:
CREATE TABLE person (
id SERIAL,
name TEXT
)

wird automatisch in:
CREATE SEQUENCE person_id_seq;
CREATE TABLE person (
id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
name TEXT
);

umgewandelt.

Die automatisch generierte Sequenz besitzt immer folgenden Namen:
''tabellederspalte''-''namederspalte''_seq

Die Man-Page zu CREATE SEQUENCE beinhaltet mehr Informationen zu Sequenzen.

Es gibt auch einen Typ BIGSERIAL, dieser unterscheidet sich aber nur darin dass die Spalte den Typ BIGINTEGER bekommt. BIGSERIAL sollte verwendet werden wenn es zu erwarten ist, dass mehr als 2 Milliarden Sequenz-Werte verwendet werden.

=== Wie bekomme ich den Wert einer SERIAL-Sequenz? ===

Eine Möglichkeit wäre, mit der nextval()-Funktion den nächsten SERIAL-Wert von dem Sequenzobjekt vor der Auszuführung einer INSERT-Anweisung anzufordern und ihn dann explizit in die INSERT-Anweisung einzubinden. Anhand der Beispieltabelle in 4.11.1 könnte dieser Vorgang in einer Pseudosprache so aussehen:

new_id = output of execute("SELECT nextval('person_id_seq')");
execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");

Danach stünde der neue Wert in der Variablen new_id für die Verwendung in weiteren Abfragen zur Verfügung, zum Beispiel als Fremdschlüssel zur Tabelle 'person'). Bitte beachten Sie, dass der Name des automatisch erstellten SEQUENCE-Objektes folgenden Name hat: «table»_«serialcolumn»_seq wobei 'table' und 'serialcolumn' die Namen
der jeweils betreffenden Tabelle / Spalte darstellen.

Als weitere Möglichkeit können Sie nach einer INSERT-Anweisung den automatisch eingefügten SERIAL-Wert mit der currval()-Funktion zurückgeben lassen:

execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
new_id = output of execute("SELECT currval('person_id_seq')");

Die einfachste Möglichkeit ist es RETURNING zu verwenden. Ein einfaches Beispiel sähe so aus:
INSERT INTO person (name) VALUES ('Blaise Pascal') RETURNING id;

=== Führt currval() zu einer Race-Condition mit anderen Nutzern? ===

Nein. currval() liefert einen Wert zurück, der von Ihrer
Datenbank-Session bestimmt wird, und der anderen Sessionen nicht zur
Verfügung steht.

=== Warum werden die Sequenzwerte nach einem Transaktionsabbruch nicht zurückgesetzt? Warum gibt es Lücken in der Nummerierung meiner Sequenz-/SERIAL-Spalte? ===

Um die gleichzeitige Abarbeitung von Transaktionen zu verbessern,
werden Sequenzen gerade nicht für andere Transaktionen gesperrt,
sondern die Sequenznummern werden den laufenden Transaktionen sofort
zugeteilt. Lücken in der Sequenznummerierung werden durch abgebrochene
Transaktionen verursacht.

=== Was ist ein OID? ===

Jede Zeile, die in PostgreSQL erzeugt wird, bekommt eine eindeutige OID, sofern die Tabelle nicht mit der Option WITHOUT OIDS angelegt wurde. OIDs sind automatisch zugewiesene 4-Byte-Integer, die innerhalb der gesamten Datenbank einmalig sind. Allerdings laufen sie bei einem Wert von ungefähr 4 Milliarden über. PostgreSQL verwendet OIDs, um
seine interne Systemtabellen zu verbinden.

Um einmalige Idenfikatoren in Datentabellen zu erstellen, wird allerdings empfohlen, statt OIDs Werte zu verwenden, die von SERIAL-Sequenzen erzeugt werden. SERIAL-Sequenzen sind innerhalb einer Tabelle einmalig und daher weniger anfällig für Überläufe. Außerdem können 8-Byte-Sequenzwerte mit BIGSERIAL (SERIAL8) erzeugt werden.

=== Was ist ein CTID? ===

CTIDs werden benutzt, um bestimmte physikalische Zeilen durch Block und Offset Werte zu identifizieren. CTIDs verändern sich, sobald Zeilen verändert oder zurückgeladen werden. Sie werden in Indexeinträgen benutzt um auf die physikalischen Zeilen zu zeigen.

=== Wieso bekomme ich einen Fehler: "ERROR: Memory exhausted in AllocSetAlloc()"? ===

Wahrscheinlich gibt es keinen virtuellen Speicher mehr in Ihrem System
oder Ihr Kernel hat niedrige Höchstgrenzen für bestimmte Ressourcen.
Probieren Sie vor dem Start von postmaster folgendes:
ulimit -d 262144
limit datasize 256m

Je nach benutzter Shell wird nur einer dieser Befehle erfolgreich
ausgeführt werden. Auf jedem Fall wird die Grenze des Datensegments
für Prozesse erhöht werden und eventuell die erfolgreiche Ausführung
der Abfrage ermöglichen. Falls Sie ein Problem mit dem SQL-Client
haben, weil das Backend zu viele Daten zurückliefert, versuchen Sie
dies vor dem Start des SQL-Clients.

=== Wie kann ich feststellen, welche PostgreSQL-Version bei mir läuft? ===

Geben Sie in psql SELECT VERSION(); ein.

=== Wie kann ich eine Spalte erstellen, deren Default-Wert immer die aktuelle Uhrzeit enthalten soll? ===

Dazu verwenden Sie CURRENT_TIMESTAMP:
CREATE TABLE test (x INT, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

=== Wie führe ich eine OUTER JOIN durch? ===

PostgreSQL unterstützt OUTER JOINs nach dem SQL- Standardsyntax. Hier
zwei Beispiele:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 ON (t1.spalte = t2.spalte)

bzw.:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 USING (spalte)

Diese identischen Abfragen verknüpfen tabelle_1 mit tabelle_2 über die
Spalte 'spalte' und geben außerdem alle unverknüpften Zeilen in
tabelle_1 (diejenigen, die keine Entsprechung in tabelle_2 haben)
zurück. Ein RIGHT JOIN würde hingegen alle unverknüpften Zeilen in
tabelle_2 hinzufügen und ein FULL JOIN würde alle verknüpften Zeilen
sowie jeweils alle unverknüpften Zeilen aus den beiden Tabellen
zurückliefern. Die Angabe von OUTER ist nicht zwingend und kann in
LEFT, RIGHT und FULL-Verknüpfungen weggelassen werden. Normale
Verknüpfungen sind INNER JOINs.

=== Wie kann ich Abfragen über mehrere Datenbanken hinweg ausführen? ===

Es gibt keinen Weg, innerhalb einer Abfrage auf mehr als eine
Datenbank zuzugreifen. Da PostgreSQL datenbank-spezifische
Systemkataloge lädt, ist eine datenbankübergreifende Abfrage nicht
möglich.

contrib/dblink ist eine Erweiterung, die datenbankübergreifende
Abfragen über Funktionsaufrufe ermöglicht.

=== Wie kann ich mehrere Zeilen bzw. Spalten von einer Funktion zurückgeben lassen? ===

Funktionen können mehrere Zeilen und Spalten zurückgeben, vgl.:
http://www.postgresql.org/docs/techdocs.17.

=== Warum bekomme ich eine Fehlermeldung wie "relation with OID ##### does not exist" wenn ich temporäre Tabellen in PL/PgSQL-Funktionen benutze? ===

In PostgreSQL-Versionen vor 8.3 verarbeitet PL/PgSQL Funktionen in
einer Cache. Dies hat eine unangenehme Nebenwirkung, nämlich dass wenn
eine PL/PgSQL-Funktion auf eine temporäre Tabelle zugreift, und diese
Tabelle anschließend gelöscht bzw. neu erstellt wird, die Funktion
fehlschlagen wird, da die gecachten Funktionsinhalte noch auf die alte
temporäre Tabelle zeigen. Die Lösung für diese Probleme besteht darin,
in der PL/PgSQL- Funktion mittels EXECUTE auf temporäre Tabellen
zuzugreifen. Dies bewirkt, dass bei jedem Funktionsruf die betreffende
Abfrage neu geparst wird.

Dieses Problem taucht in PostgreSQL 8.3 und späteren Versionen nicht
mehr auf.

=== Welche Replikationslösungen gibt es? ===

Der Begriff "replikation" umfasst mehrere verschiedene Technologien,
jede mit eigenen Vor- und Nachteilen. [http://www.postgresql.org/docs/8.3/static/high-availability.html| Die Dokumentation enthält eine gute Einführung in das Thema Replikation]

Mit "Master/slave"-Replikation werden Änderungen in einer
Hauptdatenbank durchgeführt und an "Sklaven" verteilt, die im
Nur-Lese-Modus arbeiten. Die populärste Lösung für PostgreSQL ist
Slony-I.

"Multi-master replication" ermöglicht sowohl lesende als auch
schreibende Zugriffe über mehrere Datenbank-Server hinweg. Allerdings
hat diese Art von Replikation eine negative Auswirkung auf die
Performanz durch die Notwendigkeit, Änderungen zwischen Servern zu
synchronisieren. Pgcluster ist die populärste freie Lösung für
PostgreSQL.

Es gibt auch einige kommerzielle und hardware-basierte
Replikationslösungen für verschiedene Arten der Replikation.

=== Warum werden die Tabellen- und Spaltennamen in meiner Abfrage nicht erkannt? Warum werden Großbuchstaben umgewandelt? ===

Die häufigste Ursache ist die Verwendung von Gänsefüßchen bei der
Anlegung von Tabellen, z.B.:
CREATE TABLE "Tabelle"
("SPALTE1" INT)

Dadurch werden Tabellen- und Spaltennamen (sog. Identifikatoren) in
genau der Schreibweise gespeichert (vgl. Dokumentation), was dazu
führt, dass man sie danach immer in Gänsefüßchen angeben muss. Im
obigen Beispiel muss man also immer etwa SELECT * FROM "Tabelle"
verwenden. Um dieses Problem zu vermeiden, müssen Sie immer eines der
folgenden Punkte beachten:

* bei der Tabellenanlegung keine Gänsefüßchen verwenden;
* in Identifikatoren nur Kleinschreibung verwenden;
* immer Identifikatoren mit Gänsefüßchen versehen

== Anmerkungen des Übersetzers ==

Die englische Vorlage dieser FAQ wird ständig überarbeitet. Daher
liegt die Übersetzung nicht immer auf dem aktuellsten Stand.

Die aktuellste Version der deutschen Übersetzung befindet sich immer
unter http://sql-info.de/de/postgresql/FAQ_german.html. Diese
"Arbeitsversion" enthält eventuell Änderungen, die noch nicht auf der
PostgreSQL-Website eingebunden worden sind.

Über Verbesserungshinweise und Korrekturvorschläge sowie
Verständnisfragen zum Inhalt der FAQ freue ich mich. Ich nehme auch
allgemeine Fragen zu PostgreSQL gerne entgegen, verweise jedoch auf
die Mailing-Listen als schnelle und zuverlässige Anlaufstellen.

[[Category:FAQ]]

FAQ/de

2011-12-06T18:37:44Z

Mastermind: correct markup to make the links working

{{Languages}}

== Allgemeine Fragen ==

=== Was ist PostgreSQL? Wie wird es ausgesprochen? ===

Die (englische) Aussprache ist "Post-Gres-Q-L". Im allgemeinen
Sprachgebrauch hat sich die Kurzform "Postgres" auch durchgesetzt.
(Für diejenigen, die es interessiert: eine MP3-Datei mit der
amerikanischen Aussprache befindet sich hier:
http://www.postgresql.org/files/postgresql.mp3

PostgreSQL ist ein objektrelationales Datenbanksystem, das die Vorzüge
von kommerziellen Datenbanksystemen mit zukunftsweisenden Innovationen
kombiniert. PostgreSQL ist freie Software und dessen kompletter
Quellcode ist öffentlich verfügbar.

Die PostgreSQL-Entwicklung wird von einem Team von meist freiwilligen
Entwicklern durchgeführt. Dieses Team ist für die Gesamtentwicklung
von PostgreSQL verantwortlich. Es handelt sich um ein
Gemeinschaftsprojekt, das nicht von einer bestimmten Firma
kontrolliert wird. Lesen Sie die Entwickler-FAQ:
http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn Sie an einer
Mitarbeit interessiert sind.

=== Wer kontrolliert PostgreSQL? ===

Falls Sie nach dem Namen eines etwaigen Inhabers bzw. nach einem
allmächtigen Zentralkommittee suchen - sparen Sie sich die Mühe, sowas
existiert gar nicht. Es gibt zwar das "Core Committee" sowie
Entwickler, die CVS-Schreibberechtigung haben, jedoch haben diese
Gruppen eher nur eine administrative Rolle. Das Projekt wird durch die
Community gesteuert, die aus den Entwicklern sowie natürlich auch den
Nutzern besteht - jeder kann daran teilnehmen. (Lesen Sie die
Entwickler-FAQ: http://www.postgresql.org/docs/faqs.FAQ_DEV.html wenn
Sie an der PostgreSQL-Entwicklung teilnehmen möchten).

=== Welchem Copyright unterliegt PostgreSQL? ===

PostgreSQL wird unter der klassischen BSD-Lizenz herausgegeben. Im
Grunde genommen erlaubt diese den Nutzern, beliebig mit dem Code
umzugehen, auch der Weiterverkauf von Binärversionen ohne Quellcode
ist erlaubt. Die einzige Einschränkung besteht darin, dass PostgreSQL
auf keinen Fall für etwaige Probleme mit der Software haftet. Außerdem
muß der Copyright- Text in allen Kopien der Software enthalten sein.
Dies ist der Originaltext der BSD-Lizenz:

PostgreSQL Data Base Management System

Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group
Portions Copyright (c) 1994-6 Regents of the University of California

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose, without fee, and without a written
agreement is hereby granted, provided that the above copyright notice
and this paragraph and the following two paragraphs appear in all
copies.

IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY
FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES,
INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND
ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE
PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF
CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT,
UPDATES, ENHANCEMENTS, OR MODIFICATIONS.

Es gilt die Copyright-Klausel im Original!

=== Auf welchen Plattformen läuft PostgreSQL? ===

Normalerweise kann PostgreSQL auf jeder modernen UNIX-kompatiblen
Plattform eingesetzt werden. Diejenigen Plattformen, die bei der
jeweiligen Versionsfreigabe getestet wurden, sind in den
Installationsanleitungen aufgelistet.

PostgreSQL läuft auch auf Microsoft NT-basierten Betriebssystemen wie
Windows 2000 SP4, XP und Server 2003. Ein vorgefertigtes
Installationspaket kann von http://pgfoundry.org/projects/pginstaller
heruntergeladen werden. DOS-basierte Windows-Versionen (Win95, Win98,
WinMe) können PostgreSQL nur mit Hilfe der Cygwin-Umgebung ausführen.

=== Woher bekomme ich PostgreSQL? ===

Per Web-Browser hier: http://www.postgresql.org/ftp/ und per FTP hier:
ftp://ftp.postgresql.org/pub/.

=== Was ist die neueste Version von PostgreSQL? ===

Die neueste Version von PostgreSQL kann auf der [http://www.postgresql.org/ Website] eingesehen werden.

Die Freigabe einer neuen Hauptversion erfolgt in der Regel jährlich, kleinere Korrekturversionen alle paar Monaten. Die kleineren Updates werden "Minor"-Updates, die großen jährlich erscheinenden "Major"-Updates genannt. "Minor"-Update erscheinen in der Regel gleichzeitig für alle unterstützten "Major"-Versionen. [http://www.postgresql.org/support/versioning| Falls Sie dieses Thema interessiert sollten Sie hier weiterlesen.]

=== Wo bekomme ich Support für PostgreSQL? ===

Die PostgreSQL-Community bietet Unterstützung per Mailing-Liste. Die
Web-Seite http://www.postgresql.org/community/lists/ bietet einen
Überblick. Die Listen general und bugs bieten einen guten Einstieg.

Eine deutschsprachige Mailing-Liste gibt es hier:
http://archives.postgresql.org/pgsql-de-allgemein/.

Der wichtigsten IRC-Channel ist #postgresql auf Freenode
(irc.freenode.net). Unter UNIX/Linux können Sie mit z.B. irc -c
'#postgresql' "$USER" irc.freenode.net. daran teilnehmen. Auf Freenode
gibt es folgende Channels:
* #postgresql-es (spanisch)
* #postgresqlfr (französischen)
* #postgresql-br (brasilianischen)

Es gibt außerdem einen PostgreSQL-Channel bei EFNet.

Eine Liste von Unternehmen, die Support für PostgreSQL auf kommerzieller Basis leisten, kann unter http://www.postgresql.org/support/professional_support eingesehen werden.

=== Wie kann ich einen Fehlerbericht abgeben? ===

Nutzen Sie das Formular unter
http://www.postgresql.org/support/submitbug. Schauen Sie aber vorher
unter ftp://ftp.postgresql.org/pub/ nach, ob es mittlerweile eine
neuere PostgreSQL-Version gibt, in der der Fehler behoben wurde.

Bugs, die über das Formular bzw. eine der Mailing-Listen
bekanntgegeben wurden, erhalten typischerweise einer der folgenden
Reaktionen:

* es ist kein Bug, der Grund wird benannt
* es ist ein bereits bekannter Bug, der bereits auf der TODO-Liste aufgenommen wurde
* der Bug wurde in der aktuellen Version behoben
* der Bug wurde bereits behoben, befindet sich aber noch nicht in einer offiziell veröffentlichten Version
* es wird um eingehendere Informationen gebeten, z.B.:
** Betriebssystem
** PostgreSQL-Version
** reproduzierbares Fallbeispiel
** Debugging-Information
** Debugger-Backtrace-Ausgabe
* der Bug ist neu. Folgendes könnte passieren:
** ein Patch wird erstellt und in der nächsten Version eingebaut
** der Bug kann nicht sofort behoben werden und wird auf die TODO-Liste gesetzt

=== Wie erfahre ich von bekannten Bugs oder fehlenden Features? ===

PostgreSQL unterstützt eine erweiterte Teilmenge von SQL:2003. Siehe
unsere TODO-Liste unter http://www.postgresql.org/docs/faqs.TODO.html
für eine Auflistung der bekannten Bugs, fehlenden Features und
zukünftigen Pläne.

Eine Anfrage nach einem neuen Feature führt normalerweise zu einer der
folgenden Antworten:

* das Feature ist bereits auf der TODO-Liste
* das Feature ist nicht wünschenswert, weil:
** es vorhandene Funktionalität dupliziert, welche bereits dem SQL-Standard folgt
** es würde die Komplexität der Code-Basis erhöhen, ohne nennenswerte Vorteile zu bringen
** es wäre unsicher bzw. unzuverlässig
* das neue Feature wird der TODO-Liste hinzugefügt

PostgreSQL verwendet kein Bugtracking-System, da es sich als effizienter erwiesen hat, E-Mails direkt zu beantworten und die TODO-Liste aktuell zu halten. In der Praxis werden Bugs sehr schnell beseitigt, und diejenigen Bugs, die Auswirkungen auf eine große Anzahl von Nutzern haben, werden meist kurzfristig korrigiert. Der einzige Überblick über alle Änderungen, Verbesserungen und Korrekturen in einer PostgreSQL-Version befindet sich in den CVS-Log-Meldungen. Auch die Release-Notes listen nicht jede Änderung in der Software auf.

=== Welche Dokumentation ist für PostgreSQL verfügbar? ===

PostgreSQL bietet umfangreiche Dokumentation, darunter ein großes
Handbuch, man-Pages und einige kleine Testprogramme. Siehe das /doc-
Verzeichnis. Ausserdem sind alle Handbücher online unter
http://www.postgresql.org/docs/ verfügbar.

Zwei Bücher zu PostgreSQL sind online verfügbar unter
http://www.postgresql.org/docs/books/awbook.html und
http://www.commandprompt.com/ppbook/ .

Eine Liste lieferbarer PostgreSQL-Bücher befindet sich unter
http://www.postgresql.org/docs/books Diverse technische Artikel
befinden sich unter http://www.postgresql.org/docs/techdocs .

psql hat einige nützliche \d-Befehle, um Informationen über Typen,
Operatoren, Funktionen, Aggregate, usw. zu zeigen.

Die PostgreSQL-Website enthält noch mehr Dokumentation.

=== Wie kann ich SQL lernen? ===

Die oben erwähnten PostgreSQL-spezifische Bücher bieten einen guten
Einstieg. Viele PostgreSQL-Anwender mögen "The Practical SQL Handbook"
(Bowman et al., Addison Wesley). Andere dagegen mögen "The Complete
Reference SQL" (Groff et al., McGraw-Hill).

Es gibt ausserdem einige nützliche Online-Tutorials:

* http://www.intermedia.net/support/sql/sqltut.shtm
* http://sqlcourse.com
* http://www.w3schools.com/sql/default.asp
* http://mysite.verizon.net/Graeme_Birchall/id1.html

=== Wie kann ich im Entwicklerteam mitarbeiten? ===

Lesen Sie in der Entwickler-FAQ unter
[[Developer_FAQ | Developer FAQ]] nach.

=== Wie läuft PostgreSQL im Vergleich zu anderen Datenbanksystemen? ===

Es gibt verschiedene Methoden, Software zu messen: Eigenschaften,
Performanz, Zuverlässigkeit, Support und Preis.

==== Eigenschaften ====

PostgreSQL besitzt die meisten Eigenschaften - wie
Transaktionen, Unterabfragen (Subqueries), Trigger, Views,
referenzielle Integrität bei Fremdschlüsseln und verfeinertes
Locking - die bei großen kommerziellen DBMS vorhanden sind. Es
bietet außerdem einige anderen Eigenschaften, die diese nicht
immer haben, wie benutzerbestimmte Typen, Vererbung, Regeln,
und die Multi-Versionen-Steuerung zum Verringern
konkurrierender Locks.

==== Performanz ====
Die Performanz von PostgreSQL ist mit der von kommerziellen und
anderen Open-Source-Datenbanken vergleichbar. In manchen
Bereichen ist es schneller, in anderen langsamer. In der Regel
beträgt der Unterschied +/-10%.

==== Zuverlässigkeit ====
Es ist selbstredend, dass ein DBMS wertlos ist, wenn es nicht
zuverlässig arbeitet. Daher bemühen wir uns, nur streng
geprüften und beständigen Code freizugeben, der nur ein Minimum
an Programmfehlern aufweist. Jede Freigabe hat mindestens einen
Monat Betatest-Phase hinter sich, und unsere Freigabehistorie
beweist, dass wir stabile und solide Versionen freigeben, die
im Produktionsbetrieb genutzt werden können. Wir glauben, dass
wir im Vergleich mit anderer Datenbanksoftware vorteilhaft
dastehen.

==== Support ====
Unsere Mailinglisten bieten die Möglichkeit, gemeinsam mit
einer großen Gruppe von Entwicklern und Benutzern mögliche
Probleme zu lösen. Wir können nicht immer eine Fehlerbehebung
garantieren, kommerzielle DBMS tun dies aber auch nicht. Der
direkte Kontakt zur Entwickler- und Benutzergemeinschaft und
der Zugriff auf die Handbücher und den Quellcode ermöglicht
einen im Vergleich zu anderen DBMS höherwertigeren Support. Es
gibt jedoch auch Anbieter von kommerziellen Support-Leistungen
(siehe FAQ-Punkt 1.7).

==== Preis ====
PostgreSQL ist frei verfügbar, sowohl für die kommerzielle wie
auch für die nicht-kommerzielle Nutzung. Sie können den
PostgreSQL-Code ohne Einschränkungen (außer denjenigen, die in
der oben angegebene BSD-artigen Lizenz erwähnt werden) in Ihr
Produkt integrieren.

=== Kann PostgreSQL eingebettet (embedded) werden? ===
PostgreSQL basiert auf einer Server/Client-Architektur, diese benötigt separate Prozesse für jeden Klient und Server, hinzukommen auch noch weitere "Helfer-Prozesse" (z. B. für autovacuum und stats-collector). Zwar können einige "embedded-Architekturen" diese Anforderungen erfüllen, aber wenn der Datenbank-Prozess innerhalb des Applikations-Prozesses laufen muss, kann PostgreSQL nicht verwendet werden. Dazu sollte man leichtere Datenbanken nehmen.

=== Wie kann ich mich von einer Maillingliste abmelden? Wie verhindere ich es, dass ich doppelte E-Mails bekomme? ===
Majordomo ermöglicht es sich von allen Maillinglisten an- und abzumelden, ggf. müssen Sie sich zuerst ihr Majordomo-Passwort zuschicken lassen.
[http://mail.postgresql.org/mj/mj_wwwusr|PostgreSQLs Majordomo erreichen Sie hier.]

Die PostgreSQL-Maillinglisten sind so konfiguriert, dass Antworten an den ursprünglichen Autor und an die Maillingliste verschickt werden. Somit soll erreicht werden dass Benutzer immer schnellstmöglichst eine Antwort erhalten können. Diese Einstellungen können Sie auch über die Konfiguration von Majordomo ändern, ändern Sie dafür die Einstellung für ''eliminatecc''. Sie können auch einstellen dass Sie selbst keine Antwort auf Ihre eigenen E-Mails bekommen, ändern sie dafür die Einstellung für ''selfcopy''.
[http://mail.postgresql.org/mj/mj_wwwusr|PostgreSQLs Majordomo erreichen Sie hier.]

== Fragen zu Benutzerprogrammen ==

=== Welche Schnittstellen gibt es für PostgreSQL? ===

Die PostgreSQL-Installation stellt nur Schnittstellen für C und
Embedded C bereit. Alle weitere Schnittstellen sind unabhängige
Projekte, die einzeln heruntergeladen werden werden müssen. Diese
Trennung ermöglicht individuelle Entwickler-Teams und
Entwicklungszyklen für die jeweiligen Projekte.

Einige Programmiersprachen wie PHP haben eine PostgreSQL-
Schnittstelle bereits eingebaut. Schnittstellen für Sprachen wie Perl,
TCL, Python und viele anderen sind unter http://gborg.postgresql.org
im Bereich Drivers/Interfaces verfügbar sowie per Internet-Suche.

=== Wie kann man PostgreSQL in einer Website nutzen? ===

Eine nette Einführung zu datenbank-gestützten Webseiten kann unter
http://www.webreview.com (engl.) eingesehen werden.

Für die Web-Integration ist PHP eine ausgezeichnete Schnittstelle. PHP
gibt es bei http://www.php.net

Desweiteren bietet sich die Perl-Schnittstelle mit CGI.pm
oder mod_perl auch an.

=== Hat PostgreSQL eine grafische Benutzerschnittstelle? ===

Es gibt eine große Anzahl von GUI-Programmen für PostgreSQL - sowohl
kommerziell als auch Open-Source. [http://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools| Eine englische Liste befindet sich hier.]

== Administrative Fragen ==

=== Wie installiere ich PostgreSQL woanders als in /usr/local/pgsql? ===

Bei der Ausführung von configure die Option --prefix mit dem Zielverzeichnis angeben.

=== Wie regle ich Zugriffe von anderen Rechnern? ===

PostgreSQL ist standardmäßig so eingestellt, dass Verbindungen nur vom
lokalen Rechner über Unix Domain Sockets bzw. TCP/IP möglich sind.
Verbindungen von anderen Rechnern werden erst dann ermöglicht, wenn
Sie in der Datei postgresql.conf die Einstellung listen_addresses
anpassen, in der Datei $PGDATA/pg_hba.conf host-basierte
Authentifizierung einschalten und den Server neu starten.

=== Wie kann ich eine bessere Performanz erreichen? ===

Es gibt drei große Bereiche, in denen Performanzverbesserungen erzielt
werden können:

==== Abfrageoptimierung ====
Die Modifizierung von Abfragen kann eine bessere Performanz erzielen:

* [http://www.postgresql.org/docs/current/interactive/indexes.html Erstellung von Indexen, einschliesslich partieller Indexe sowie Expressionsindexe]
* Einsatz von COPY anstelle multipler INSERT-Anweisungen
* Gruppierung von mehreren Abfragen innerhalb einer Transaktion, um Aufwand beim Abschluss von Transaktionen einzusparen
* Einsatz von CLUSTER beim Holen von einer großen Anzahl von Datenreihen aus einem Index
* Einsatz von LIMIT, um eine Untermenge der Abfragenergebnisse zurückzuliefern
* [http://www.postgresql.org/docs/current/interactive/sql-prepare.html Einsatz von vorbereiteten Befehlen (prepared queries)]
* Einsatz von ANALYZE, um die Datenbankstatistik für den Abfragenplaner aktuell zu halten
* [http://www.postgresql.org/docs/current/static/routine-vacuuming.html Regelmäßiger Einsatz von VACUUM bzw. pg_autovacuum (autovacuum ist seit Version 8.3 standardmäßig aktiviert)]
* Bei großen Datenveränderungen die Löschung von Indexen

==== Server-Konfiguration ====
Einige Einstellungen in der Datei postgresql.conf wirken sich auf die Performanz aus. Das Handbuch enthält unter http://www.postgresql.org/docs/current/static/runtime-config.html eine komplette Auflistung.

Kommentare zu den jeweiligen Einstellungen gibt es unter http://www.varlena.com/varlena/GeneralBits/Tidbitsannotated_conf_e.html und http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html.

==== Hardware-Auswahl ====
Die Auswirkung von Hardware auf Performanz wird unter http://momjian.us/main/writings/pgsql/hw_performance/index.html und http://www.powerpostgresql.com/PerfList/ erläutert.

=== Welche Debugging-Funktionen sind für PostgreSQL verfügbar? ===

Unter den Optionen für die Server-Konfigurierung gibt es zahlreiche
log_*-Variablen, die die Ausgabe von Abfrage- und Prozessstatistiken
ermöglichen. Diese können für Debugging-Zwecke sowie Performanz-Tests
sehr nützlich sein.

=== Ich bekomme die Meldung "Sorry, too many clients", wenn ich eine Verbindung aufzubauen versuche. Warum? ===

Ihr System hat die maximal zulässige Anzahl von Datenbankverbindungen
erreicht (Voreinstellung 100). Sie müssen die maximale Anzahl der
gleichzeitig ausführbaren Backend-Prozesse hochsetzen, indem Sie in
postgresql.conf den Wert max_connections ändern und den Server
neustarten.

=== Wie wird PostgreSQL aktualisiert? ===

Allgemeine Informationen zur Aktualisierung von PostgreSQL gibt es auf
der Seite http://www.postgresql.org/support/versioning. Detaillierte
technische Informationen gibt es auf der Seite
http://www.postgresql.org/docs/current/static/install-upgrading.html

=== Kommt PostgreSQL mit den Anpassungen der Sommerzeit in verschiedenen Ländern klar? ===

Für die Berücksichtigung der Sommerzeit verwendet PostgreSQL Seit dem Release 8.0 die weiterverbreitete tzdata-Datenbank (auch bekannt als "zoneinfo database" oder "[http://www.twinsun.com/tz/tz-link.htm| Olzen timezone database]".

Jedes Update von PostgreSQL beinhaltet die aktuellen tzdata Dateien, daher sollte es reichen die Minor-Updates der eingesetzten Major Version im Auge zu behalten.

Unter der Vorraussetzung dass das Betriebssystem diese Dateien schon in einer stets aktuellen Version vorbehält, ist es üblich, dass man diese Dateien verwendet. PostgreSQL bietet dazu eine compile-option an.

=== Welche Hardware eignet sich für den Betrieb mit PostgreSQL? ===

PostgreSQL läuft auf fast jeder Hardware-Kombination. Im PC-Bereich
gibt es allerdings sehr große Abweichungen in der Qualität. Für einen
Arbeitsplatz- oder Entwicklungsrechner mag dies nicht so bedeutend
sein, im Server-Betrieb jedoch lohnt sich auf jeden Fall die
Investition in teurere Bestandteile (Stichwörter ECC-Speicher, SCSI,
Hauptplatinen und Netzteile von namhaften Herstellern). Nutzen Sie
unsere Mailing-Listen, um Hardware-Optionen zu diskutieren.

== Fragen zum Betrieb ==

=== Wie wähle ich per SELECT-Anweisung nur die ersten paar Zeilen bzw. eine beliebige Zeile in einer Abfrage aus? ===

Wenn Sie bei der Ausführung der Abfrage die Anzahl der anzufordenden
Reihen bereits kennen, nutzen Sie LIMIT. Wenn die ORDER BY- Anweisung
mit einem Index verwendet wird, ist es möglich, dass die gesamte
Abfrage nicht ausgeführt werden muss. Wenn Sie die Anzahl der der
anzufordenden Reihen nicht kennen, verwenden Sie einen Cursor und
FETCH.

Um eine beliebige Zeile auszuwählen, nutzen Sie ORDER BY random():
SELECT spalte
FROM tabelle
ORDER BY random()
LIMIT 1

=== Wie finde ich heraus, welche Tabellen, Indexe, Datenbanken oder Benutzer in der Datenbank definiert sind? Wie bekomme ich die von psql verwendeten Abfragen? ===

In psql zeigt der Befehl \dt eine Liste der Datenbanktabellen. Weitere
psql-Befehle lassen sich mit \? anzeigen. Sie können sich die Datei
pgsql/src/bin/psql/describe.c mit dem Quellcode für psql ansehen. Sie
enthält die SQL-Abfragen, die die Backslash-Kommandos (\) ausführen.
Sie können psql auch mit der -E Option starten. Danach gibt psql die
Abfragen aus, die es bei der Ausführung der Befehle benutzt. Außerdem
biete PostgreSQL ein SQL-kompatibles INFORMATION SCHEMA, das
Metainformation über die Datenbank zur Verfügung stellt.

Mit psql -l können Sie alle Datenbanken anzeigen lassen.

Die Datei pgsql/src/tutorial/syscat.source enthält außerdem viele
SELECT- Abfragen, mit deren Hilfe man Information über die
Systemtabellen erhalten kann.

=== Wie ändere ich den Datentyp einer Spalte? ===

Ab Version 8.0 kann der Datentyp einer Spalte mit ALTER TABLE ALTER
COLUMN TYPE geändert werden, sofern der neue Datentyp die Werte des
alten Datentype aufnehmen kann.

Bei früheren Versionen gehen Sie wie folgt vor:
BEGIN;
ALTER TABLE tabelle ADD COLUMN neue_spalte neuer_datentyp;
UPDATE tabelle SET neue_spalte = CAST(alte_spalte AS neuer_datentyp);
ALTER TABLE tabelle DROP COLUMN alte_spalte;
COMMIT;

Um den Speicherplatz freizugeben, der von der gelöschten Spalte
verwendet wurde, führen Sie VACUUM FULL aus.

=== Was ist die Maximalgröße für eine Zeile, eine Tabelle, eine Datenbank? ===

Es bestehen folgende Obergrenzen:
Maximale Größe eine Datenbank? unbeschränkt (es existieren
Datenbanken mit 32 TB)
Maximale Größe einer Tabelle? 32 TB
Maximale Größe einer Zeile? 400 GB
Maximale Größe einer Spalte? 1 GB
Maximale Anzahl von Zeilen in einer Tabelle?
unbeschränkt
Maximale Anzahl von Spalten in einer Tabelle?
250-1600 je nach Spaltentyp
Maximale Anzahl von Indexen für eine Tabelle?
unbeschränkt

Selbstverständlich sind dies theoretische Werte, die oft durch die
verfügbaren Platten- und Speicherressourcen beschränkt werden. Extreme
Größen können zu Leistungseinbußen führen.

Die maximale Tabellengröße von 32 TB benötigt keine
Large-File-Unterstützung im Betriebssystem. Große Tabellen werden in
Dateien mit einer Größe von je 1 GB aufgeteilt, wodurch etwaige
dateisystem-bedingte Beschränkungen nicht relevant sind.

Die maximale Tabellengröße und die maximale Anzahl von Spalten können
vervierfacht werden, indem man die Default-Blockgröße auf 32 KB
heraufsetzt. Die Tabellengröße kann auch durch Tabellenpartitionierung
vergrößert werden.

Eine Einschränkung ist, dass Indexe nur auf Spalten erstellt werden
können, die bis etwa 2.000 Zeichen groß sind. Um auf größere Spalten
eine UNIQUE-Constraint setzen zu können, nutzen Sie einen funktionalen
Index mit dem MD5-Hash-Wert der Spalte. Um innerhalb einer großen, mit
Text belegten Spalte suchen zu können, verwenden Sie einen
Volltext-Index.

=== Wieviel Plattenplatz wird benötigt, um die Daten aus einer typischen Textdatei abzuspeichern? ===

Eine PostgreSQL-Datenbank kann beim Abspeichern einer einfachen
Textdatei bis zu fünfmal mehr Platz gegenüber der eigentlichen Größe
der Datei beanspruchen.

Betrachten wir eine Datei mit 100.000 Zeilen mit einem Integer und
einer Textbeschreibung pro Zeile. Gehen wir davon aus, dass die
durchschnittliche Länge der Textbeschreibung 20 Byte beträgt. Die
einfache Datei würde 2,8 MB groß sein. Die Größe der
PostgreSQL-Datenbankdatei, die diese Daten enthält, liegt ungefähr bei
5,2 MB:
24 Bytes: jeder Zeilenkopf (ungefähr)
+24 Bytes: ein Integer-Feld und ein Textfeld
+ 4 Bytes: Zeiger auf der Datenseite auf den Tupel
-----------------------------------------------
52 Bytes pro Zeile

Die Größe einer Datenseite in PostgreSQL beträgt 8192 Bytes (8 KB),
also:
8192 Bytes pro Seite
--------------------- = 146 Zeilen pro Seite (abgerundet)
52 Bytes pro Zeile

100.000 Datenzeilen
------------------------ = 685 Datenbankseiten (aufgerundet)
158 Zeilen pro Seite

633 Datenbankseiten * 8192 Bytes pro Seite = 5,185,536 bytes (5,2 MB)

Indexe beanspruchen nicht so viel Platz. Da sie jedoch die Daten
beinhalten, die sie indizieren, können auch sie sehr groß werden.

NULL-Werte werden als Bitmaps gespeichert, wodurch sie sehr wenig
Platz in Anspruch nehmen.

=== Meine Abfragen sind langsam oder benutzen die Indexe nicht. Warum? ===

Indexe werden nicht automatisch bei jeder Abfrage verwendet. Indexe
werden nur dann verwendet, wenn die abzufragende Tabelle eine
bestimmte Größe übersteigt, und die Abfrage nur eine kleine
Prozentzahl der Tabellenzeilen abfragt. Der Grund hierfür ist der,
dass die durch einen Index verursachten Festplattenzugriffe manchmal
länger dauern würden als ein einfaches Auslesen aller Tabellenzeilen
(sequentieller Scan).

Um festzustellen, ob ein Index verwendet werden soll, braucht
PostgreSQL Statistiken über die Tabelle. Diese Statistiken werden
durch die Anweisungen VACUUM ANALYZE bzw. ANALYZE berechnet. Anhand
der Statistiken kennt der Abfragenoptimierer die Anzahl der
Tabellenzeilen und kann besser entscheiden, ob Indexe verwendet werden
sollen. Statistiken sind auch bei der Ermittlung der optimalen
JOIN-Reihenfolgen und -Methoden wertvoll. Daher sollten diese
regelmässig durchgeführt werden, da sich der Inhalt einer Tabelle ja
auch verändert.

Indexe werden normalerweise nicht in ORDER BY-Abfrage oder in JOINs
verwendet. Ein sequentieller Scan mit anschließendem explizitem
Sortiervorgang ist normalerweise schneller als ein Index-Scan einer
großen Tabelle. Jedoch wird bei einer Abfrage, in der LIMIT zusammen
mit ORDER BY verwendet wird, oftmals ein Index verwendet, da nur ein
kleiner Abschnitt der Tabelle zurückgeliefert wird.

Sollte es danach aussehen, also ob der Optimierer irrtümlich einen
sequentiellen Scan ausführt, führen Sie SET enable_seqscan TO 'off'
aus und prüfen Sie, ob die Indexabfrage dadurch scheller geworden ist.

Bei der Nutzung von Wildcard-Operatoren wie LIKE oder ~, können Indexe
nur unter bestimmten Umständen verwendet werden:

* Das Suchmuster muss sich an Anfang des Strings befinden, d.h.:
** LIKE-Suchmuster dürfen nicht mit % anfangen;
** ~ (reguläre Ausdrücke) müssen mit ^ anfangen.
* Das Suchmuster darf nicht mit einer Zeichenklasse (z.B. [a-e]) beginnen.
* Suchmuster, die Gross- und Kleinschreibung nicht berücksichtigen (z.B. ILIKE bzw. ~*), verwenden keine Indexe. Stattdessen können funktionale Indexe verwendet werden, die im Punkt 4.8 beschrieben werden.
* Die Standard-Locale "C" muss während der Datenbank-Initialisierung mit initdb verwendet worden sein, da andere locales den nächstgrößten Wert nicht ermitteln können. Es ist allerdings möglich, einen besonderen text_pattern_ops-Index für solche Fälle zu erstellen.

In Versionen vor 8.0 werden Indexe oft nicht benutzt, wenn die
jeweiligen Datentypen nicht genau übereinstimmen. Dies gilt besonders
für Indexe auf Spalten mit den Datentypen INT2, INT8 und NUMERIC

=== Auf welche Weise kann ich sehen, wie der Abfrage-Optimierer meine Abfrage auswertet? ===

Eine ausführliche Erklärung zu diesem Thema findet sich in der [http://www.postgresql.org/docs/current/static/sql-explain.html EXPLAIN] Dokumentation.

=== Wie änder ich das Sortierverhalten von textähnlichen Daten? ===
PostgreSQL sortiert Daten anhand dem bei initdb gesetzten Locale. (Ab 8.4 wird es es möglich sein pro Datenbank ein eigenes Locale zu definieren)

Entspricht das Sortierverhalten nicht dem gewünschten muss man die Locale ändern. Die meisten Locales, außer "C", sortieren anhand der Reihenfolge des entsprechenden Wörterbuches. Das Locale "C" ignoriert jegliche Punktuation und Zwischenraum.

=== Wie verfahre ich bei der Suche mit regulären Ausdrücken und bei einer Suche, bei der Groß- und Kleinschreibweisen ignoriert werden? Wie verwende ich einen Index bei solchen Suchabfragen? ===

Der Operator ~ wendet einen regulären Ausdruck an und ~* wendet ihn
an, ohne die Groß- und Kleinschreibung zu beachten. Ebenso beachtet
LIKE die Groß- und Kleinschreibung, und ILIKE nicht.

Gleichheitsvergleiche, die Groß- und Kleinschreibung ignorieren,
werden in der Regel so ausgedruckt:
SELECT *
FROM tabelle
WHERE LOWER(spalte) = 'abc'

Hier wird kein normaler Index benutzt. Legt man hingegen einen
funktionalen Index an, so wird er auf jeden Fall verwendet:
CREATE INDEX tabelle_index ON tabelle (LOWER(spalte))

Falls der obige Index als einen UNIQUE-Index angelegt wird, können
keine Werte in die Spalte eingefügt werden, die sich nur durch ihre
Groß- und Kleinschreibung unterscheiden. Um Fehler zu vermeiden muß
ein CHECK-Constraint oder ein Trigger eingesetzt werden.

=== Wie ermittle ich in einer Abfrage, ob ein Feld NULL ist? Kann nach der NULL-Belegung sortiert werden? ===

Testen Sie die Spalte mit IS NULL bzw. IS NOT NULL.
SELECT
*
FROM
tabelle
WHERE
spalte IS NULL

Beim konkatenieren mit einen NULL-Wert wir das Ergebnis auch NULL. Um dies zu verhindern verwenden Sie am besten [http://www.postgresql.org/docs/current/static/functions-conditional.html| COALESCE()]
SELECT
COALESCE(col1, '') || COALESCE(col2, '')
FROM tab;

Um die Spalte danach zu sortieren, ob sie mit NULL belegt ist oder nicht, verwenden Sie die Bedingungen IS NULL bzw. IS NOT NULL in der ORDER BY-Klausel. Da Bedingungen, die wahr sind, höher als das Gegenteil sortiert werden, bewirkt die folgende Abfrage, dass die NULL-Spalten zuerst gelistet werden:
SELECT
*
FROM
tabelle
ORDER BY
(spalte IS NOT NULL)

Ab PostreSQL 8.3 und höher, ist es möglich das standardisierte NULLS FIRST/NULLS LAST zu verwenden um die Position der NULL-Werte im Ergebnis zu bestimmen. (bei FIRST stehen diese zu erst, bei LAST am Ende)
SELECT
*
FROM
tab
ORDER BY
col NULLS FIRST;

=== Was ist der Unterschied zwischen den verschiedenen CHAR-Typen? ===
{| border="1"
!Typ
!interner Name
!Bemerkungen
|-
|VARCHAR(n)
|varchar
|die Größe legt die Maximallänge fest; kein Auffüllen mit Leerzeichen
|-
|CHAR(n)
|bpchar
|mit Leerzeichen gefüllt bis zur angegebenen Länge
|-
|TEXT
|text
|keine obere Grenze für die Länge
|-
|BYTEA
|bytea
|Bytearray mit variabler Länge (auch für '\0'-Bytes geeignet)
|-
|"char" (with the quotes)
|char
|ein Zeichen
|}

Der interne Name kommt vor allem in den Systemkatalogen und in manchen
Fehlermeldungen vor.

Die ersten vier Typen sind "varlena"-Typen (d.h. die ersten vier Bytes
geben die Länge an, gefolgt von den Daten). Daher ist der tatsächlich
belegte Platz immer etwas mehr als die deklarierte Feldgröße.
Allerdings wird unter Umständen auf diese Datentypen Datenkompression
durch das TOAST- Verfahren angewendet, womit der tatsächlich belegte
Platz auch geringer als erwartet ausfallen kann.

Für die Speicherung von Zeichenketten variabler Länge empfiehlt sich
VARCHAR(n). Die maximale Länge eines VARCHAR(n)-Felds wird bei der
Tabellendefinition festgelegt. TEXT setzt keine Längengrenze,
allerdings gibt es eine systembedingte Obergrenze von 1 GB.

CHAR(n) ist geeignet für die Speicherung von Zeichenketten, die alle
die gleiche Länge haben. Bitte beachten Sie, dass CHAR(n) automatisch
Zeichenketten bis zur definierten Feldlänge mit Leerzeichen ausfüllt,
während bei VARCHAR(n) nur die tatsächlich eingegebene Zeichenkette
gespeichert wird.

BYTEA ist für binäre Daten, besonders für Werte, die NULL-Bytes haben.

Alle der hier erwähnten Typen weisen ähnliche Performanzeigenschaften
auf.

=== Wie erzeuge ich ein serielles Feld mit automatischer Erhöhung des Wert? ===

PostgreSQL bietet einen SERIAL-Datentyp. Dies ist zwar kein richtiger Datentyp. Es ist die Kurzform für das Erstellen einer Spalte vom Typ Integer, die von einer Sequenz befüllt wird.

Zum Beispiel:
CREATE TABLE person (
id SERIAL,
name TEXT
)

wird automatisch in:
CREATE SEQUENCE person_id_seq;
CREATE TABLE person (
id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
name TEXT
);

umgewandelt.

Die automatisch generierte Sequenz besitzt immer folgenden Namen:
''tabellederspalte''-''namederspalte''_seq

Die Man-Page zu CREATE SEQUENCE beinhaltet mehr Informationen zu Sequenzen.

Es gibt auch einen Typ BIGSERIAL, dieser unterscheidet sich aber nur darin dass die Spalte den Typ BIGINTEGER bekommt. BIGSERIAL sollte verwendet werden wenn es zu erwarten ist, dass mehr als 2 Milliarden Sequenz-Werte verwendet werden.

=== Wie bekomme ich den Wert einer SERIAL-Sequenz? ===

Eine Möglichkeit wäre, mit der nextval()-Funktion den nächsten SERIAL-Wert von dem Sequenzobjekt vor der Auszuführung einer INSERT-Anweisung anzufordern und ihn dann explizit in die INSERT-Anweisung einzubinden. Anhand der Beispieltabelle in 4.11.1 könnte dieser Vorgang in einer Pseudosprache so aussehen:

new_id = output of execute("SELECT nextval('person_id_seq')");
execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");

Danach stünde der neue Wert in der Variablen new_id für die Verwendung in weiteren Abfragen zur Verfügung, zum Beispiel als Fremdschlüssel zur Tabelle 'person'). Bitte beachten Sie, dass der Name des automatisch erstellten SEQUENCE-Objektes folgenden Name hat: «table»_«serialcolumn»_seq wobei 'table' und 'serialcolumn' die Namen
der jeweils betreffenden Tabelle / Spalte darstellen.

Als weitere Möglichkeit können Sie nach einer INSERT-Anweisung den automatisch eingefügten SERIAL-Wert mit der currval()-Funktion zurückgeben lassen:

execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
new_id = output of execute("SELECT currval('person_id_seq')");

Die einfachste Möglichkeit ist es RETURNING zu verwenden. Ein einfaches Beispiel sähe so aus:
INSERT INTO person (name) VALUES ('Blaise Pascal') RETURNING id;

=== Führt currval() zu einer Race-Condition mit anderen Nutzern? ===

Nein. currval() liefert einen Wert zurück, der von Ihrer
Datenbank-Session bestimmt wird, und der anderen Sessionen nicht zur
Verfügung steht.

=== Warum werden die Sequenzwerte nach einem Transaktionsabbruch nicht zurückgesetzt? Warum gibt es Lücken in der Nummerierung meiner Sequenz-/SERIAL-Spalte? ===

Um die gleichzeitige Abarbeitung von Transaktionen zu verbessern,
werden Sequenzen gerade nicht für andere Transaktionen gesperrt,
sondern die Sequenznummern werden den laufenden Transaktionen sofort
zugeteilt. Lücken in der Sequenznummerierung werden durch abgebrochene
Transaktionen verursacht.

=== Was ist ein OID? ===

Jede Zeile, die in PostgreSQL erzeugt wird, bekommt eine eindeutige OID, sofern die Tabelle nicht mit der Option WITHOUT OIDS angelegt wurde. OIDs sind automatisch zugewiesene 4-Byte-Integer, die innerhalb der gesamten Datenbank einmalig sind. Allerdings laufen sie bei einem Wert von ungefähr 4 Milliarden über. PostgreSQL verwendet OIDs, um
seine interne Systemtabellen zu verbinden.

Um einmalige Idenfikatoren in Datentabellen zu erstellen, wird allerdings empfohlen, statt OIDs Werte zu verwenden, die von SERIAL-Sequenzen erzeugt werden. SERIAL-Sequenzen sind innerhalb einer Tabelle einmalig und daher weniger anfällig für Überläufe. Außerdem können 8-Byte-Sequenzwerte mit BIGSERIAL (SERIAL8) erzeugt werden.

=== Was ist ein CTID? ===

CTIDs werden benutzt, um bestimmte physikalische Zeilen durch Block und Offset Werte zu identifizieren. CTIDs verändern sich, sobald Zeilen verändert oder zurückgeladen werden. Sie werden in Indexeinträgen benutzt um auf die physikalischen Zeilen zu zeigen.

=== Wieso bekomme ich einen Fehler: "ERROR: Memory exhausted in AllocSetAlloc()"? ===

Wahrscheinlich gibt es keinen virtuellen Speicher mehr in Ihrem System
oder Ihr Kernel hat niedrige Höchstgrenzen für bestimmte Ressourcen.
Probieren Sie vor dem Start von postmaster folgendes:
ulimit -d 262144
limit datasize 256m

Je nach benutzter Shell wird nur einer dieser Befehle erfolgreich
ausgeführt werden. Auf jedem Fall wird die Grenze des Datensegments
für Prozesse erhöht werden und eventuell die erfolgreiche Ausführung
der Abfrage ermöglichen. Falls Sie ein Problem mit dem SQL-Client
haben, weil das Backend zu viele Daten zurückliefert, versuchen Sie
dies vor dem Start des SQL-Clients.

=== Wie kann ich feststellen, welche PostgreSQL-Version bei mir läuft? ===

Geben Sie in psql SELECT VERSION(); ein.

=== Wie kann ich eine Spalte erstellen, deren Default-Wert immer die aktuelle Uhrzeit enthalten soll? ===

Dazu verwenden Sie CURRENT_TIMESTAMP:
CREATE TABLE test (x INT, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

=== Wie führe ich eine OUTER JOIN durch? ===

PostgreSQL unterstützt OUTER JOINs nach dem SQL- Standardsyntax. Hier
zwei Beispiele:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 ON (t1.spalte = t2.spalte)

bzw.:
SELECT *
FROM tabelle_1 t1
LEFT OUTER JOIN tabelle_2 t2 USING (spalte)

Diese identischen Abfragen verknüpfen tabelle_1 mit tabelle_2 über die
Spalte 'spalte' und geben außerdem alle unverknüpften Zeilen in
tabelle_1 (diejenigen, die keine Entsprechung in tabelle_2 haben)
zurück. Ein RIGHT JOIN würde hingegen alle unverknüpften Zeilen in
tabelle_2 hinzufügen und ein FULL JOIN würde alle verknüpften Zeilen
sowie jeweils alle unverknüpften Zeilen aus den beiden Tabellen
zurückliefern. Die Angabe von OUTER ist nicht zwingend und kann in
LEFT, RIGHT und FULL-Verknüpfungen weggelassen werden. Normale
Verknüpfungen sind INNER JOINs.

=== Wie kann ich Abfragen über mehrere Datenbanken hinweg ausführen? ===

Es gibt keinen Weg, innerhalb einer Abfrage auf mehr als eine
Datenbank zuzugreifen. Da PostgreSQL datenbank-spezifische
Systemkataloge lädt, ist eine datenbankübergreifende Abfrage nicht
möglich.

contrib/dblink ist eine Erweiterung, die datenbankübergreifende
Abfragen über Funktionsaufrufe ermöglicht.

=== Wie kann ich mehrere Zeilen bzw. Spalten von einer Funktion zurückgeben lassen? ===

Funktionen können mehrere Zeilen und Spalten zurückgeben, vgl.:
http://www.postgresql.org/docs/techdocs.17.

=== Warum bekomme ich eine Fehlermeldung wie "relation with OID ##### does not exist" wenn ich temporäre Tabellen in PL/PgSQL-Funktionen benutze? ===

In PostgreSQL-Versionen vor 8.3 verarbeitet PL/PgSQL Funktionen in
einer Cache. Dies hat eine unangenehme Nebenwirkung, nämlich dass wenn
eine PL/PgSQL-Funktion auf eine temporäre Tabelle zugreift, und diese
Tabelle anschließend gelöscht bzw. neu erstellt wird, die Funktion
fehlschlagen wird, da die gecachten Funktionsinhalte noch auf die alte
temporäre Tabelle zeigen. Die Lösung für diese Probleme besteht darin,
in der PL/PgSQL- Funktion mittels EXECUTE auf temporäre Tabellen
zuzugreifen. Dies bewirkt, dass bei jedem Funktionsruf die betreffende
Abfrage neu geparst wird.

Dieses Problem taucht in PostgreSQL 8.3 und späteren Versionen nicht
mehr auf.

=== Welche Replikationslösungen gibt es? ===

Der Begriff "replikation" umfasst mehrere verschiedene Technologien,
jede mit eigenen Vor- und Nachteilen. [http://www.postgresql.org/docs/8.3/static/high-availability.html| Die Dokumentation enthält eine gute Einführung in das Thema Replikation]

Mit "Master/slave"-Replikation werden Änderungen in einer
Hauptdatenbank durchgeführt und an "Sklaven" verteilt, die im
Nur-Lese-Modus arbeiten. Die populärste Lösung für PostgreSQL ist
Slony-I.

"Multi-master replication" ermöglicht sowohl lesende als auch
schreibende Zugriffe über mehrere Datenbank-Server hinweg. Allerdings
hat diese Art von Replikation eine negative Auswirkung auf die
Performanz durch die Notwendigkeit, Änderungen zwischen Servern zu
synchronisieren. Pgcluster ist die populärste freie Lösung für
PostgreSQL.

Es gibt auch einige kommerzielle und hardware-basierte
Replikationslösungen für verschiedene Arten der Replikation.

=== Warum werden die Tabellen- und Spaltennamen in meiner Abfrage nicht erkannt? Warum werden Großbuchstaben umgewandelt? ===

Die häufigste Ursache ist die Verwendung von Gänsefüßchen bei der
Anlegung von Tabellen, z.B.:
CREATE TABLE "Tabelle"
("SPALTE1" INT)

Dadurch werden Tabellen- und Spaltennamen (sog. Identifikatoren) in
genau der Schreibweise gespeichert (vgl. Dokumentation), was dazu
führt, dass man sie danach immer in Gänsefüßchen angeben muss. Im
obigen Beispiel muss man also immer etwa SELECT * FROM "Tabelle"
verwenden. Um dieses Problem zu vermeiden, müssen Sie immer eines der
folgenden Punkte beachten:

* bei der Tabellenanlegung keine Gänsefüßchen verwenden;
* in Identifikatoren nur Kleinschreibung verwenden;
* immer Identifikatoren mit Gänsefüßchen versehen

== Anmerkungen des Übersetzers ==

Die englische Vorlage dieser FAQ wird ständig überarbeitet. Daher
liegt die Übersetzung nicht immer auf dem aktuellsten Stand.

Die aktuellste Version der deutschen Übersetzung befindet sich immer
unter http://sql-info.de/de/postgresql/FAQ_german.html. Diese
"Arbeitsversion" enthält eventuell Änderungen, die noch nicht auf der
PostgreSQL-Website eingebunden worden sind.

Über Verbesserungshinweise und Korrekturvorschläge sowie
Verständnisfragen zum Inhalt der FAQ freue ich mich. Ich nehme auch
allgemeine Fragen zu PostgreSQL gerne entgegen, verweise jedoch auf
die Mailing-Listen als schnelle und zuverlässige Anlaufstellen.

[[Category:FAQ]]

PostgreSQL Conference Europe Talks 2011

2011-10-19T16:18:35Z

Mastermind: add datacenter slide

= PostgreSQL Conference Europe 2011 Talks =

== Talks: Wednesday 18th October, 2011 ==

=== Ams 1 ===
* [[Media:Mohan_PGCon_Keynote_10-19-2011.pdf|Ram Mohan Keynote: Afilias Winning Bet on Open Source]]
* [http://www.oslandia.com/files/1646fd60f9b0a4558d1e256cf3264572/pgconfeu2011_vincent_picavet_postgis.pdf Vincent Picavet - Geo in your database : Postgis]
* [http://pgeu-plv8.herokuapp.com Will Leinweber: heralding the death of nosql]

=== Ams 2 ===

* [http://ora2pg.darold.net/ora2pg-best-practices.pdf Gilles Darold: Best practices with Ora2Pg]

=== Ams 3 ===

* [[Media:Ciolli-window-2011.pdf|Gianni Ciolli, Look Out The Window Functions (and free your SQL)]]
plus four 2D heat diffusion movies, with different starting scenarios: [[http://vimeo.com/30797130 a hot point]],
[[http://vimeo.com/30797509 a hot segment]],
[[http://vimeo.com/30797715 a hot square]] and
[[http://vimeo.com/30797797 a cold square]].
* [[Media:Smartgrid_for_the_datacenter_web.pdf|Stefan Kaltenbrunner, A smartgrid for the datacenter]]

== Talks: Thursday 19th October, 2011 ==

=== Ams 1 ===

=== Ams 2 ===

=== Ams 3 ===

== Talks: Friday 20th October, 2011 ==

=== Ams 1 ===

=== Ams 2 ===

=== Ams 3 ===

File:Smartgrid for the datacenter web.pdf

2011-10-19T16:16:45Z

Mastermind: A smartgrid for the datacenter

A smartgrid for the datacenter

PostgreSQL Release Support Policy

2011-10-01T19:39:09Z

Mastermind: mark the whole rows in italics for EOL'd releases to make the table a bit more readable

The PostgreSQL project aims to fully support a major release for '''five years''', under the terms of the [http://www.postgresql.org/support/versioning Versioning policy]

After a release falls out of full support, we may (at our committers' discretion) continue to apply further critical fixes to the source code, on a best-effort basis. No formal releases or binary packages will be produced by the project, but the updated source code will be available from our source code control system.

This policy will be followed on a best-effort basis. In extreme cases it may not be possible to support a release for the planned lifetime; for example if a serious bug is found that cannot be resolved in a given major version without significant risk to the stability of the code or loss of application compatibility. In such cases, early retirement of a major version may be required.

The first version update released after the EOL date will normally be the final one for that version. Note that this can extend support shortly past the listed date. For example, [http://www.postgresql.org/docs/7.4/static/release.html 7.4.30] and [http://www.postgresql.org/docs/8.0/static/release.html 8.0.26] were the EOL releases for those two versions. They were originally targeted for EOL as of July 2010, but those final versions were not actually released until October 2010.

=== End Of Life (EOL) dates ===

Releases which have already reached an EOL release are italicized:

{| cellspacing="0" cellpadding="5" border="1"
!Version
!EOL Date
!Release Date
|-
|''PostgreSQL 7.4''
|''October 2010 (extended)''
|''November 2003''
|-
|''PostgreSQL 8.0''
|''October 2010 (extended)''
|''January 2005''
|-
|''PostgreSQL 8.1''
|''November 2010''
|''November 2005''
|-
|PostgreSQL 8.2
|December 2011
|December 2006
|-
|PostgreSQL 8.3
|February 2013
|February 2008
|-
|PostgreSQL 8.4
|July 2014
|July 2009
|-
|PostgreSQL 9.0
|September 2015
|September 2010
|-
|PostgreSQL 9.1
|September 2016
|September 2011
|}

PostgreSQL Release Support Policy

2011-10-01T19:19:51Z

Mastermind: add 9.1

The PostgreSQL project aims to fully support a major release for '''five years''', under the terms of the [http://www.postgresql.org/support/versioning Versioning policy]

After a release falls out of full support, we may (at our committers' discretion) continue to apply further critical fixes to the source code, on a best-effort basis. No formal releases or binary packages will be produced by the project, but the updated source code will be available from our source code control system.

This policy will be followed on a best-effort basis. In extreme cases it may not be possible to support a release for the planned lifetime; for example if a serious bug is found that cannot be resolved in a given major version without significant risk to the stability of the code or loss of application compatibility. In such cases, early retirement of a major version may be required.

The first version update released after the EOL date will normally be the final one for that version. Note that this can extend support shortly past the listed date. For example, [http://www.postgresql.org/docs/7.4/static/release.html 7.4.30] and [http://www.postgresql.org/docs/8.0/static/release.html 8.0.26] were the EOL releases for those two versions. They were originally targeted for EOL as of July 2010, but those final versions were not actually released until October 2010.

=== End Of Life (EOL) dates ===

Releases which have already reached an EOL release are italicized:

{| cellspacing="0" cellpadding="5" border="1"
!Version
!EOL Date
!Release Date
|-
|''PostgreSQL 7.4''
|October 2010 (extended)
|November 2003
|-
|''PostgreSQL 8.0''
|October 2010 (extended)
|January 2005
|-
|''PostgreSQL 8.1''
|November 2010
|November 2005
|-
|PostgreSQL 8.2
|December 2011
|December 2006
|-
|PostgreSQL 8.3
|February 2013
|February 2008
|-
|PostgreSQL 8.4
|July 2014
|July 2009
|-
|PostgreSQL 9.0
|September 2015
|September 2010
|-
|PostgreSQL 9.1
|September 2016
|September 2011
|}

Tracker:BugzillaTest

2011-05-29T18:04:06Z

Mastermind: remove dead link to trackerdemo installation

== PgTracker Demo Installation ==

the old demo installation ran on a modified version of Bugzilla 3.0. It is had the following additional features over the stock version:

* full integration with the main website community login feature
* better creation of bugs via the email interface
* integration with the main website bug reporting form via the XML-RPC interface
* modifications to the internal API for some operations (like being able to "impersonate" reporters over the XML-RPC interface to get correct attribution)

=== basic concepts ===

pgtracker is currently supposed to be a bug and issue tracker primarily for pgsql-bugs@. It does not intent to replace the mailinglist in any way but it is supposed to augment and support it.
To do that the main bug reporting form on the Website is now generating a Bug report using the XML-RPC interface(so that BZ can drive the generation of the bug id which needs to be unique).

The resulting bug is either:

* only made visible to people part of the "Tracker Team" in case it is a normal bug report

* only made visible to people part of the "Security Team" in case it is reported as a security bug

"visible" in this context means that the bug cannot be viewed by the public and needs to be verified by a member of the respective team. Those bugs are initially tagged as UNCONFIRMED which is a special state that will not cause any (email) notifications to be sent.
This scheme can support both bugs sent via the bug reporting form and bugs submitted by the native BZ interface.
Issues on pgsql-bugs@postgresql.org however tend to generate responses (both "this is not a bug" and "oh yeah this is a bug please try the following patch") pretty quickly - to cope with that the bugzilla installation is subscribed to the mailinglist and will simply add each reply as a comment to the tracker entry.

XXX: discuss handling of mails sent directly to the list

=== email interface ===

the bugzilla installation provides an email based interface that can be used or basic interaction with the tracker. The interface [http://www.bugzilla.org/docs/3.0/html/api/email_in.html#Modifying_an_Existing_Bug is documented here].

this docs lack a bit of information on what fields one can manipulate through that interface so here are some examples:

replying to a bugreport with:

<code>
@resolution = INVALID
this is not a bug please look at the docs to find out why
</code>

in the body of an email will result in the mentioned bug to get:

* a status of "RESOLVED"
* a resolution of "INVALID"
* a comment of "this is not a bug please look at the docs to find out why"

(selected) list of available commands(all ned to be prefixed with an @ to be recognized by the email interface):

<code>
bug_id -- bug identifer (needs to be either in the Subject in the form of "[Bug 1234]" or mentioned in the mail)
short_desc -- sets/updates the summary text of the bug
classification
product -- name of the product (ie PostgreSQL)
version -- PostgreSQL Version
rep_platform
op_sys -- Operating system
bug_status -- Status of the bug (one of RESOLVED,ASSIGNED,REOPENED,CLOSED,VERIFIED)
status_whiteboard
keywords
resolution -- sets the resolution of the bug (one of FIXED, INVALID, WORKSFORME, DUPLICATE, WONTFIX)
bug_severity
priority
component -- component this bug can be attributed too
assigned_to
qa_contact
cc
dependson
blocked
longdesc
content
</code>

'''WARNING: the current version of the email interface will only recognize commands if it is in the very first line of the email'''

=== bug states ===

general descriptions of the available bug states are available [http://trackerdemo.postgresql.org/page.cgi?id=fields.html#status here]

* UNCONFIRMED (this state is only visible to members of the bug tracker team)
* NEW (this is the default state for all accepted bugs)
* ASSIGNED
* REOPENED
* VERIFIED
* CLOSED

=== components ===

* plperl
* plpgsql
* optimizer
* documentation
* psql
* backend
* contrib
* libpq

=== loose ends ===

* robustify the email interface
* make the site look prettier
* emails sent directly to the list
* submit some of our modifications to upstream
* deal with people changing their emailaddress in the community login profile
* document that bz can only deal with the emailaddress for login and not the username
* explain the "logged in vs. not" business
* commands are case sensitive ie. "@resolution=wontfix" != "@resolution=WONTFIX"
* automatically handle attachments

TrackerDiscussion

2011-05-29T17:59:52Z

Mastermind: remove the "talk to me before you edit" - per discussion on -hackers

This is purely a space to dump some of the stuff that was discussed on the now defunct tracker list and has no real official character.

See [[Tracker:BugzillaTest]] for information on our test tracker.

=== basic criteria ===

==== basic technical and operational requirements ====

* must work on common unix platforms
* must support postgresql as a backend
* must require no/minimal customization work for community adoption
* must have community login integration

==== Management of bugs and issues ====

{| border="1" cellpadding="1" cellspacing="0" style="font-size: 85%; border: gray solid 1px; border-collapse: collapse; text-align: center; width: 100%; table-layout: fixed;"
|- style="background: #ececec"
! style="width:16em" |
! Requirement (yes/no/optional)
! Bugzilla 3.0
|-
! style="text-align:block;" bgcolor="#ececec" | Creation of bugs
| bgcolor="#ddffdd" | yes
| bgcolor="#ddffdd" | yes
|-
! style="text-align:block;" bgcolor="#ececec" | Creation of bugs via web interface
| bgcolor="#ddffdd" | yes
| bgcolor="#ddffdd" | yes
|-
! style="text-align:block;" bgcolor="#ececec" | Creation of bugs via mail interface
| bgcolor="#ddffdd" | optional
| bgcolor="#ddffdd" | yes
|-
! style="text-align:block;" bgcolor="#ececec" | Creation of bugs via external interface
| bgcolor="#ddffdd" | optional
| bgcolor="#ddffdd" | yes
|-
! style="text-align:block;" bgcolor="#ececec" colspan="3" |
|-
! style="text-align:block;" bgcolor="#ececec" | Ability to query open bugs
| bgcolor="#ddffdd" | yes
| bgcolor="#ddffdd" | yes
|-
! style="text-align:block;" bgcolor="#ececec" | Ability to query open bugs via web interface
| bgcolor="#ddffdd" | yes
| bgcolor="#ddffdd" | yes
|-
! style="text-align:block;" bgcolor="#ececec" | Ability to query open bugs via external interface
| bgcolor="#ddffdd" | yes
| bgcolor="#ddffdd" | yes(SOAP/XML-RPC)
|-
! style="text-align:block;" bgcolor="#ececec" colspan="3" |
|-
! style="text-align:block;" bgcolor="#ececec" | Ability to query historical bug data
| bgcolor="#ddffdd" | yes
| bgcolor="#ddffdd" | yes
|-
! style="text-align:block;" bgcolor="#ececec" | Ability to change/set bug status
| bgcolor="#ddffdd" | yes
| bgcolor="#ddffdd" | yes
|-
! style="text-align:block;" bgcolor="#ececec" | Ability to set and track people working on a given bug
| bgcolor="#ddffdd" | yes
| bgcolor="#ddffdd" | yes
|-
! style="text-align:block;" bgcolor="#ececec" | Ability to categorize bugs by severity and release
| bgcolor="#ddffdd" | yes
| bgcolor="#ddffdd" | yes
|-
! style="text-align:block;" bgcolor="#ececec" | Ability to moderate bug listing (not listed publicly until evaluator accepts)
| bgcolor="#ddffdd" | yes
| bgcolor="#ddffdd" | ?
|-
! style="text-align:block;" bgcolor="#ececec" | Full-text searching of bug reports
| bgcolor="#ddffdd" | yes
| bgcolor="#ddffdd" | ?
|-
! style="text-align:block;" bgcolor="#ececec" | Links to source control system events
| bgcolor="#ddffdd" | optional
| bgcolor="#ddffdd" | ?
|}

==== Management of feature requests ====

{| border="1" cellpadding="1" cellspacing="0" style="font-size: 85%; border: gray solid 1px; border-collapse: collapse; text-align: center; width: 100%; table-layout: fixed;"
|- style="background: #ececec"
! style="width:16em" |
! Requirement (yes/no/optional)
! Bugzilla 3.0
|-
! style="text-align:block;" bgcolor="#ececec" | Creation of feature requests
| bgcolor="#ddffdd" | yes
| bgcolor="#ddffdd" | yes
|-
! style="text-align:block;" bgcolor="#ececec" | Creation of feature requests via web interface
| bgcolor="#ddffdd" | yes
| bgcolor="#ddffdd" | yes
|-
! style="text-align:block;" bgcolor="#ececec" | Creation of feature requests via mail interface
| bgcolor="#ddffdd" | yes
| bgcolor="#ddffdd" | yes
|-
! style="text-align:block;" bgcolor="#ececec" | Creation of feature requests via external interface
| bgcolor="#ddffdd" | optional
| bgcolor="#ddffdd" | yes (soap/XML-RPC)
|}

=== Record Keeping ===
# Some way of capturing the discussion around feature requests
# Some way of capturing links to the mailing list discussion around feature requests
# Ability to reject feature requests (for historical purposes)
# Link between feature request/discussion and bug that triggered the request
=== Ease of use for developers ===
# Low overhead in accessing the system
# Email interface
# Some way of uploading content (design plans, &c.)
# Easy way of linking trouble reports together
# Plain delineations (i.e. just the right number of categories, modules, &c.)
# Obvious how to use (not a lot of work to start using)
# Can be used by "experts" (f. doesn't make the tool so dumb that experienced users have to click 43 things all the time.)
# At least as reliable as CVS
# Facilities for flexible "triage" work
=== Ease of use for community members ===
# Web interface
# Communications about bugs are regular and understandable (no "report/request to black hole")
=== Ease of use for "non-community members" (e.g. new users, users who don't follow mailing lists regularly, &c.) ===
# Bug reports are easy to make (don't need to create an account just to file a bug).

Performance QA Testing

2011-05-20T18:40:16Z

Mastermind: /* Datasets */

This page centralizes the efforts on performances QA testing: available hardware, available tools, continuous benchmarking effort...

The PostgreSQL Performance lab is being created to allow community members of the Open Source database [http://www.postgresql.org/ PostgreSQL] to have enterprise class hardware to test on.

The testing that will occur includes industry standard workloads such as OLTP, DSS and BI. Furthermore we will also use the hardware for other practical and customer oriented testing to improve scalability (processor utilization, i/o, load balancing, etc.) and managing large data sets (loading, backups, restores, replication, etc).

=== Donations ===

For donation inquiries, please contact [mailto:josh@postgresql.org Josh Berkus <josh @t postgresql.org>] and [mailto:jdrake@postgresql.org Joshua Drake <jdrake @t postgresql.org>].

=== Mailing List ===

There is a [http://lists.pgfoundry.org/mailman/listinfo/perflab-general mailing list] available to discuss administrative aspects of community equipment. Please continue to use the -hackers and -performance mailing lists for performance and technical discussions.

== QA platforms ==

* [[QA Platform hosted at Command Prompt]] - Portland, Oregon, USA
* [[QA Platform hosted at Open Wide (France)]]

== Tools ==

* Former OSDL work: [http://osdldbt.sourceforge.net/ Database Test Suite] and [http://crucible.svn.sourceforge.net/viewvc/crucible/ Web interface]
* [http://www.westnet.com/~gsmith/content/postgresql/pgbench-tools.htm pgbench-tools from Greg Smith]. See [[Regression Testing with pgbench]].
* [http://bristlecone.continuent.org/HomePage Bristlecone from Continuent]
* [http://tsung.erlang-projects.org/ Tsung load injector] allows to define sessions (containing queries and thinktime, etc) and replay them with very high concurrency setup. Can use many loading nodes at a time, multi OS support (written in [http://www.erlang.org/ erlang], extensible in this language)
* [http://dim.tapoueh.org/temp/tsung-plotter/ Tsung Plotter] plots several tsung runs onto the same graphs set, for easy comparing. Uses python and matplotlib.
* Tsung DBT2 Implementation (tsung module in erlang), WIP, to get published asap.

== Ideas ==

* look into [http://sysbench.sourceforge.net/ sysbench] - it has some issues with locking on postgresql but at least read-only it seems to work fine. See [[SysBench]] for more info.

* collecting all the various small samples and testcases posted over the last few years on -performance, -hackers & -bugs and put them into a test set

* consider doing tests using pgbench -M (simple|extended|prepared) to catch regressions in one of those modes

* resurrect Jan Wiecks tpc-w implementation available on [http://pgfoundry.org/projects/tpc-w-php/ pgfoundry]

* add full text search benchmarking by using [http://www.sigaev.ru/cvsweb/cvsweb.cgi/ftsbench/ ftsbench] from teodor

* XML benchmarking ?

* investigate [http://advogato.org/person/nconway/diary.html?start=21 QuickCheck] and http://advogato.org/person/nconway/diary/23.html

* Implement the [http://www.cs.umb.edu/~poneil/StarSchemaB.PDF Star Schema Benchmark].

== Datasets ==

[[Sample_Databases|see the sample databases page for some free datasources]]

== Information ==
* [http://wiki.postgresql.org/wiki/Performance_Optimization In depth performance articles on PostgreSQL]
* [http://wiki.postgresql.org/wiki/HP_ProLiant_DL380_G5_Tuning_Guide DL380 Tuning Guide]
* [http://www.vimeo.com/channels/postgres Videos on Performance and other topics]
* [http://www.commandprompt.com/blogs/joshua_drake/2008/04/is_that_performance_i_smell_ext2_vs_ext3_on_50_spindles_testing_for_postgresql/ Performance measurements between load and filesystems (Linux)]

[[Category:Benchmarking]]

Performance QA Testing

2011-05-20T18:35:33Z

Mastermind: refer to the free sample dataset page instead of having the information in both places

This page centralizes the efforts on performances QA testing: available hardware, available tools, continuous benchmarking effort...

The PostgreSQL Performance lab is being created to allow community members of the Open Source database [http://www.postgresql.org/ PostgreSQL] to have enterprise class hardware to test on.

The testing that will occur includes industry standard workloads such as OLTP, DSS and BI. Furthermore we will also use the hardware for other practical and customer oriented testing to improve scalability (processor utilization, i/o, load balancing, etc.) and managing large data sets (loading, backups, restores, replication, etc).

=== Donations ===

For donation inquiries, please contact [mailto:josh@postgresql.org Josh Berkus <josh @t postgresql.org>] and [mailto:jdrake@postgresql.org Joshua Drake <jdrake @t postgresql.org>].

=== Mailing List ===

There is a [http://lists.pgfoundry.org/mailman/listinfo/perflab-general mailing list] available to discuss administrative aspects of community equipment. Please continue to use the -hackers and -performance mailing lists for performance and technical discussions.

== QA platforms ==

* [[QA Platform hosted at Command Prompt]] - Portland, Oregon, USA
* [[QA Platform hosted at Open Wide (France)]]

== Tools ==

* Former OSDL work: [http://osdldbt.sourceforge.net/ Database Test Suite] and [http://crucible.svn.sourceforge.net/viewvc/crucible/ Web interface]
* [http://www.westnet.com/~gsmith/content/postgresql/pgbench-tools.htm pgbench-tools from Greg Smith]. See [[Regression Testing with pgbench]].
* [http://bristlecone.continuent.org/HomePage Bristlecone from Continuent]
* [http://tsung.erlang-projects.org/ Tsung load injector] allows to define sessions (containing queries and thinktime, etc) and replay them with very high concurrency setup. Can use many loading nodes at a time, multi OS support (written in [http://www.erlang.org/ erlang], extensible in this language)
* [http://dim.tapoueh.org/temp/tsung-plotter/ Tsung Plotter] plots several tsung runs onto the same graphs set, for easy comparing. Uses python and matplotlib.
* Tsung DBT2 Implementation (tsung module in erlang), WIP, to get published asap.

== Ideas ==

* look into [http://sysbench.sourceforge.net/ sysbench] - it has some issues with locking on postgresql but at least read-only it seems to work fine. See [[SysBench]] for more info.

* collecting all the various small samples and testcases posted over the last few years on -performance, -hackers & -bugs and put them into a test set

* consider doing tests using pgbench -M (simple|extended|prepared) to catch regressions in one of those modes

* resurrect Jan Wiecks tpc-w implementation available on [http://pgfoundry.org/projects/tpc-w-php/ pgfoundry]

* add full text search benchmarking by using [http://www.sigaev.ru/cvsweb/cvsweb.cgi/ftsbench/ ftsbench] from teodor

* XML benchmarking ?

* investigate [http://advogato.org/person/nconway/diary.html?start=21 QuickCheck] and http://advogato.org/person/nconway/diary/23.html

* Implement the [http://www.cs.umb.edu/~poneil/StarSchemaB.PDF Star Schema Benchmark].

== Datasets ==

[[Sample_Databases see the sample databases page for some free datasources]]

== Information ==
* [http://wiki.postgresql.org/wiki/Performance_Optimization In depth performance articles on PostgreSQL]
* [http://wiki.postgresql.org/wiki/HP_ProLiant_DL380_G5_Tuning_Guide DL380 Tuning Guide]
* [http://www.vimeo.com/channels/postgres Videos on Performance and other topics]
* [http://www.commandprompt.com/blogs/joshua_drake/2008/04/is_that_performance_i_smell_ext2_vs_ext3_on_50_spindles_testing_for_postgresql/ Performance measurements between load and filesystems (Linux)]

[[Category:Benchmarking]]

Sample Databases

2011-05-20T18:30:29Z

Mastermind:

Many database systems provide sample databases with the product. A good intro to popular ones that includes discussion of samples available for other databases is [http://www.barik.net/archive/2006/03/28/195425/ Sample Databases for PostgreSQL and More]

One trivial sample that PostgreSQL ships with is the [[Pgbench]]. This has the advantage of being built-in and supporting a scalable data generator--you can make databases of any size ranging from 16MB to 600GB (approximately) with the current version.

== PgFoundry Samples ==

The latest collection of PostgreSQL compatible database samples is at [http://pgfoundry.org/projects/dbsamples/ PgFoundry Sample Databases]. It includes three commonly used benchmark databases:

* World: Based on the [http://dev.mysql.com/doc/world-setup/en/world-setup.html MySQL World] sample. Has a list of Cities, Countries, and what language they speak.
* dellstore2: PostgreSQL port of a database-neutral e-commerce test application [http://linux.dell.com/dvdstore/ developed by Dell]. The original code supports three size scales in their data generator (10MB, 1GB, 100GB), currently only the normal, smallest sized data set has been ported to PostgreSQL. [http://www.storytotell.org/blog/2009/08/12/postgresql-84-windowing-functions.html PostgreSQL 8.4: Windowing Functions] uses this test data to show some advanced queries.
* Pagilia: Based on MySQL's replacement for World, [http://dev.mysql.com/doc/sakila/en/sakila.html Sakila], which is itself inspired by the Dell DVD Store.

There are some other sample databases there as well, such as a USDA Food database and a large list of country data via ISO-3166 standards.

== Other Samples ==

* [http://www.commandprompt.com/ppbook/booktown.sql Book Town] - used for the examples in [http://www.commandprompt.com/ppbook/ Practical PostgreSQL]
* Benchmarking databases such as [[DBT-2]] or [[TPC-H]] can be used as samples.
* [http://www.freebase.com/docs/data_dumps Freebase] - Various wiki style data on places/people/things - ~600MB compressed
* [http://www.imdb.com/interfaces#plain IMDB] - the IMDB database - see also http://code.google.com/p/imbi/
* [http://www.data.gov/ ] - US federal government data collection see also [http://www.sunlightlabs.com/ sunlightlabs]
* [http://wiki.dbpedia.org/Downloads DBpedia] - wikipedia data export project
* [http://www.eoddata.com/ eoddata] - historic stock market data (requires registration - licence?)
* [http://www.transtats.bts.gov/Tables.asp?DB_ID=120&DB_Name=Airline%20On-Time%20Performance%20Data&DB_Short_Name=On-Time RITA] - Airline On-Time Performance Data
* [http://wiki.openstreetmap.org/wiki/Planet.osm Openstreetmap] - Openstreetmap source data

Sample Databases

2011-05-20T18:29:27Z

Mastermind: move sample databases over from the Performance QA page

Many database systems provide sample databases with the product. A good intro to popular ones that includes discussion of samples available for other databases is [http://www.barik.net/archive/2006/03/28/195425/ Sample Databases for PostgreSQL and More]

One trivial sample that PostgreSQL ships with is the [[Pgbench]]. This has the advantage of being built-in and supporting a scalable data generator--you can make databases of any size ranging from 16MB to 600GB (approximately) with the current version.

== PgFoundry Samples ==

The latest collection of PostgreSQL compatible database samples is at [http://pgfoundry.org/projects/dbsamples/ PgFoundry Sample Databases]. It includes three commonly used benchmark databases:

* World: Based on the [http://dev.mysql.com/doc/world-setup/en/world-setup.html MySQL World] sample. Has a list of Cities, Countries, and what language they speak.
* dellstore2: PostgreSQL port of a database-neutral e-commerce test application [http://linux.dell.com/dvdstore/ developed by Dell]. The original code supports three size scales in their data generator (10MB, 1GB, 100GB), currently only the normal, smallest sized data set has been ported to PostgreSQL. [http://www.storytotell.org/blog/2009/08/12/postgresql-84-windowing-functions.html PostgreSQL 8.4: Windowing Functions] uses this test data to show some advanced queries.
* Pagilia: Based on MySQL's replacement for World, [http://dev.mysql.com/doc/sakila/en/sakila.html Sakila], which is itself inspired by the Dell DVD Store.

There are some other sample databases there as well, such as a USDA Food database and a large list of country data via ISO-3166 standards.

== Other Samples ==

* [http://www.commandprompt.com/ppbook/booktown.sql Book Town] - used for the examples in [http://www.commandprompt.com/ppbook/ Practical PostgreSQL]
* Benchmarking databases such as [[DBT-2]] or [[TPC-H]] can be used as samples.
* [http://www.freebase.com/docs/data_dumps Freebase] - Various wiki style data on places/people/things - ~600MB compressed
* [http://www.imdb.com/interfaces#plain IMDB] - the IMDB database - see also http://code.google.com/p/imbi/
* [http://www.data.gov/ ] - US federal government data collection see also [http://www.sunlightlabs.com/ sunlightlabs]
* [http://wiki.dbpedia.org/Downloads DBpedia] - wikipedia data export project
* [http://linux.dell.com/dvdstore/ Dell DVDstore] - Dells DVD Store context data
* [http://www.eoddata.com/ eoddata] - historic stock market data (requires registration - licence?)
* [http://www.transtats.bts.gov/Tables.asp?DB_ID=120&DB_Name=Airline%20On-Time%20Performance%20Data&DB_Short_Name=On-Time RITA] - Airline On-Time Performance Data
* [http://wiki.openstreetmap.org/wiki/Planet.osm Openstreetmap] - Openstreetmap source data

[[Category:Benchmarking]]

PGDay Europe 2010 Talks

2010-12-07T14:09:30Z

Mastermind: link in the right slides

PGDay.EU 2010 was held in Stuttgart, Germany on December 6th - 8th.

== Monday, December 6, 2010 ==

=== Berlin 1+2 ===

==== 9:45 - 10:45 [[Keynote: Back To The Future of Open Source (Simon Phipps)]]====
==== 11:10 - 12:00 [[Play chess against PostgreSQL (and get beaten) (Gianni Ciolli)]] ====
==== 12:10 - 13:00 [[Rapid Upgrades With Pg_Upgrade (Bruce Momjian)]] ====
==== 14:00 - 14:50 [[PostGIS 1.5 and beyond: a technical perspective (Mark Cave-Ayland, Olivier Courtin)]] ====
==== 15:20 - 16:10 [[Managing PostgreSQL Replication (Simon Riggs)]] ====

=== Berlin 3 ===

==== 11:10 - 12:00 [[PostGIS - Das Wo? in der Datenbank (Stefan Keller, Andreas Neumann)]]====

==== 12:10 - 13:00 [[PostgreSQL als Basis für Detailhandels-Anwendungen (Marc Balmer)]]====

==== 14:00 - 14:50 [[Media:Pg-community.pdf|Die PostgreSQL Community (Bernd Helmle)]]====

==== 16:20 - 17:10 [[Media:Pgday-2010-ose-print.pdf|Open Source Entscheidungen]] ([[User:Ads|Andreas Scherbaum]]) ====

=== Glasgow ===

=== Tara ===

== Tuesday, December 7, 2010 ==

=== Berlin 1+2 ===

=== Berlin 3 ===

==== 10:25 - 11:10 [[Media:Pgday_eu_2010_benchmarking.pdf|Benchmarking und Performancetesting von und mit PostgreSQL]] ([[User:mastermind|Stefan Kaltenbrunner]]) ====

==== 11:35 - 12:20 [[Media:Pgday-2010-mysql-to-pg-print.pdf|Datenbanken von MySQL zu PostgreSQL portieren]] ([[User:Ads|Andreas Scherbaum]]) ====

=== Glasgow ===

=== Tara ===

File:Pgday eu 2010 benchmarking.pdf

2010-12-07T14:08:34Z

Mastermind: Benchmarking und Performancetesting von und mit PostgreSQL

Benchmarking und Performancetesting von und mit PostgreSQL

PGDay Europe 2010 Talks

2010-12-07T14:07:00Z

Mastermind: add my talk

PGDay.EU 2010 was held in Stuttgart, Germany on December 6th - 8th.

== Monday, December 6, 2010 ==

=== Berlin 1+2 ===

==== 9:45 - 10:45 [[Keynote: Back To The Future of Open Source (Simon Phipps)]]====
==== 11:10 - 12:00 [[Play chess against PostgreSQL (and get beaten) (Gianni Ciolli)]] ====
==== 12:10 - 13:00 [[Rapid Upgrades With Pg_Upgrade (Bruce Momjian)]] ====
==== 14:00 - 14:50 [[PostGIS 1.5 and beyond: a technical perspective (Mark Cave-Ayland, Olivier Courtin)]] ====
==== 15:20 - 16:10 [[Managing PostgreSQL Replication (Simon Riggs)]] ====

=== Berlin 3 ===

==== 11:10 - 12:00 [[PostGIS - Das Wo? in der Datenbank (Stefan Keller, Andreas Neumann)]]====

==== 12:10 - 13:00 [[PostgreSQL als Basis für Detailhandels-Anwendungen (Marc Balmer)]]====

==== 14:00 - 14:50 [[Media:Pg-community.pdf|Die PostgreSQL Community (Bernd Helmle)]]====

==== 16:20 - 17:10 [[Media:Pgday-2010-ose-print.pdf|Open Source Entscheidungen]] ([[User:Ads|Andreas Scherbaum]]) ====

=== Glasgow ===

=== Tara ===

== Tuesday, December 7, 2010 ==

=== Berlin 1+2 ===

=== Berlin 3 ===

==== 10:25 - 11:10 [[Media:Pgday-2010-mysql-to-pg-print.pdf|Benchmarking und Performancetesting von und mit PostgreSQL]] ([[User:mastermind|Stefan Kaltenbrunner]]) ====
==== 11:35 - 12:20 [[Media:Pgday-2010-mysql-to-pg-print.pdf|Datenbanken von MySQL zu PostgreSQL portieren]] ([[User:Ads|Andreas Scherbaum]]) ====

=== Glasgow ===

=== Tara ===

Tracker:BugzillaTest

2010-08-17T18:08:31Z

Mastermind: remove link to my development sandbox to prevent people from accidentially trying to submit valid bugs there...

== PgTracker Demo Installation ==

http://trackerdemo.postgresql.org is running a modified version of Bugzilla 3.0. It is has the following additional features over the stock version:

* full integration with the main website community login feature
* better creation of bugs via the email interface
* integration with the main website bug reporting form via the XML-RPC interface
* modifications to the internal API for some operations (like being able to "impersonate" reporters over the XML-RPC interface to get correct attribution)

=== basic concepts ===

pgtracker is currently supposed to be a bug and issue tracker primarily for pgsql-bugs@. It does not intent to replace the mailinglist in any way but it is supposed to augment and support it.
To do that the main bug reporting form on the Website is now generating a Bug report using the XML-RPC interface(so that BZ can drive the generation of the bug id which needs to be unique).

The resulting bug is either:

* only made visible to people part of the "Tracker Team" in case it is a normal bug report

* only made visible to people part of the "Security Team" in case it is reported as a security bug

"visible" in this context means that the bug cannot be viewed by the public and needs to be verified by a member of the respective team. Those bugs are initially tagged as UNCONFIRMED which is a special state that will not cause any (email) notifications to be sent.
This scheme can support both bugs sent via the bug reporting form and bugs submitted by the native BZ interface.
Issues on pgsql-bugs@postgresql.org however tend to generate responses (both "this is not a bug" and "oh yeah this is a bug please try the following patch") pretty quickly - to cope with that the bugzilla installation is subscribed to the mailinglist and will simply add each reply as a comment to the tracker entry.

XXX: discuss handling of mails sent directly to the list

=== email interface ===

the bugzilla installation provides an email based interface that can be used or basic interaction with the tracker. The interface [http://www.bugzilla.org/docs/3.0/html/api/email_in.html#Modifying_an_Existing_Bug is documented here].

this docs lack a bit of information on what fields one can manipulate through that interface so here are some examples:

replying to a bugreport with:

<code>
@resolution = INVALID
this is not a bug please look at the docs to find out why
</code>

in the body of an email will result in the mentioned bug to get:

* a status of "RESOLVED"
* a resolution of "INVALID"
* a comment of "this is not a bug please look at the docs to find out why"

(selected) list of available commands(all ned to be prefixed with an @ to be recognized by the email interface):

<code>
bug_id -- bug identifer (needs to be either in the Subject in the form of "[Bug 1234]" or mentioned in the mail)
short_desc -- sets/updates the summary text of the bug
classification
product -- name of the product (ie PostgreSQL)
version -- PostgreSQL Version
rep_platform
op_sys -- Operating system
bug_status -- Status of the bug (one of RESOLVED,ASSIGNED,REOPENED,CLOSED,VERIFIED)
status_whiteboard
keywords
resolution -- sets the resolution of the bug (one of FIXED, INVALID, WORKSFORME, DUPLICATE, WONTFIX)
bug_severity
priority
component -- component this bug can be attributed too
assigned_to
qa_contact
cc
dependson
blocked
longdesc
content
</code>

'''WARNING: the current version of the email interface will only recognize commands if it is in the very first line of the email'''

=== bug states ===

general descriptions of the available bug states are available [http://trackerdemo.postgresql.org/page.cgi?id=fields.html#status here]

* UNCONFIRMED (this state is only visible to members of the bug tracker team)
* NEW (this is the default state for all accepted bugs)
* ASSIGNED
* REOPENED
* VERIFIED
* CLOSED

=== components ===

* plperl
* plpgsql
* optimizer
* documentation
* psql
* backend
* contrib
* libpq

=== loose ends ===

* robustify the email interface
* make the site look prettier
* emails sent directly to the list
* submit some of our modifications to upstream
* deal with people changing their emailaddress in the community login profile
* document that bz can only deal with the emailaddress for login and not the username
* explain the "logged in vs. not" business
* commands are case sensitive ie. "@resolution=wontfix" != "@resolution=WONTFIX"
* automatically handle attachments

PostgreSQL Buildfarm Howto

2010-05-29T18:57:49Z

Mastermind:

PostgreSQL BuildFarm is a distributed build system designed to detect
build failures on a large collection of platforms and configurations.
This software is written in Perl. If you're not comfortable with Perl
then you possibly don't want to run this, even though the only adjustment
you should ever need is to the config file (which is also Perl).

=== Get the Software ===
Download from: [http://pgfoundry.org/frs/?group_id=1000040 pgFoundry]
Unpack it and put it somewhere. You can put the config file in a different
place from the run_build.pl script if you want to, but the
simplest thing is to put it in the same place. Decide which user you will run
the script as - it must be a user who can run the PostgreSQL server programs (on Unix
that means it must *not* run as root). Do everything else here as that user.

=== Set up a base git mirror that all your branches will pull from. ===
Most buildfarm members run on more than one branch, and if you do it's good practice to set up
a mirror on the buildfarm machine and then just clone that for each branch. As of this writing there are two suitable public git repositories:
* git://git.postgresql.org/git/postgresql.git
* git://github.com/oicu/pg-cvs-mirror.git
The first is the community repository, and is kept very up to date. Unfortunately it is broken on
branches earlier then REL8_3_STABLE. The second repository is similar to the first but is not broken on any of the live branches (as of the current writing). When the PostgreSQL project finally moves to using Git, currently expect to be around August 2010, both of these will become redundant. To set up a mirror, do something like this:
git clone --mirror git://github.com/oicu/pg-cvs-mirror.git pgsql-base.git
When that is done, add an entry to your crontab to keep it up to date, something like:
20,50 * * * * cd /path/to/pgsql-base.git && git fetch -q

=== Create a directory where builds will run. ===
This should be dedicated to
the use of the build farm. Make sure there's plenty of space - on my
machine each branch can use up to about 700Mb during a build. You can use the
directory where the script lives, or a subdirectory of it, or a completely
different directory.

=== Edit the build-farm.conf file ===
Put the location of the directory you just
created in the config variable "build_root". Set the "scm" to "git" and the "scmrepo"
to the path to your git mirror. If you are not using the community git repo, set the "scm_url" to
point to where to find a givven git commit on the web. e.g. for my mirror on github, the scm_url should be <i>http://github.com/oicu.pg-cvs-mirror/commit/</i> (Don't forget the trailing "/".)
Adjust the config variables
"make", "config_opts", and (if you don't use ccache)
"config_env" to suit your environment, and to choose which optional postgres
coniguration options you want to build with. You should not need to adjust any other variables.
Check that you didn't screw things up by running "perl -cw build-farm.conf".

=== Change the shebang line in the run_build script. ===
If the path to your perl
installation isn't "/usr/bin/perl", edit the #! line in run_build.pl so it is correct.
This is the ONLY line in that file you should ever need to edit.

=== Check that required perl modules are present. ===
Run "perl -cw run_build.pl".
If you get errors about missing perl modules you will need to install them.
Most of the required modules are standard modules in any perl
distribution.. The rest are all standard CPAN modules, and available either from there
or from your OS distribution. When you don't get an error any more, run the same test on
run_web_txn.pl. When all is clear you are ready to start testing.

=== Run in test mode. ===
With a PATH that matches what you will have when running from cron, run
the script in no-send, no-status, verbose mode. Something like this:
./run_build.pl --nosend --nostatus --verbose
and watch the fun begin. If this results in failures because it can't
find some executables (especially gmake and git), you might need to change
the config file again, this time changing the "build_env" with another
setting something like:
PATH => "/usr/local/bin:$ENV{PATH}",
Also, if you put the config file somewhere else, you will need to use
the --config=/path/to/build-farm.conf option.

=== Test running from cron ===
When you have that running, it's time to try with cron.
Put a line in your crontab that looks something like this:
43 * * * * cd /location/of/run_build.pl/ && ./run_build.pl --nosend --verbose
Again, add the --config option if needed. Notice that this time we didn't
specify --nostatus. That means that (after the first run) the script won't
do any build work unless the Git repo has changed. Check that your cron
job runs (it should email you the results, unless you tell it to send them
elsewhere).

=== Choose which branches you want to build ===
By default run_build.pl builds the HEAD branch. If you want to
build other branches, you can do so by specifying the name on the commandline,
e.g.
run_build.pl REL8_4_STABLE
so, once you have HEAD working, remove the --verbose flag from your crontab,
and add extra cron lines for each branch you want to build regularly.
You could have something like this:
6 * * * * cd /home/andrew/buildfarm && ./run_build.pl --nosend
30 4 * * * cd /home/andrew/buildfarm && ./run_build.pl --nosend REL8_1_STABLE

=== Register your new buildfarm member. ===
Once this is all running happily, you can register to upload your
results to the central server. Registration can be done on the buildfarm server
at http://www.pgbuildfarm.org/register.html. When you receive your approval by
email, you will edit the "animal" and "secret" lines in your config file,
remove the --nosend flags, and you are done.

=== Bugs ===
Please file bug reports on the tracker at [http://pgfoundry.org/tracker/?atid=238&group_id=1000040&func=browse pgFoundry]

=== Running on Windows ===
There are three build environments for Windows: Cygwin, MinGW/MSys, and Microsoft Visual C++. The buildfarm can run with each of these environments. This section discusses requirements for the buildfarm, rather than requirements for building on Windows, which are covered elsewhere.

==== Cygwin ====
There is almost nothing extra to be done for Cygwin. You need to make sure that cygserver is running, and you should set MAX_CONNECTIONS=>3 and CYGWIN=>'server' in the build_env stanza of the buildfarm config. Other than that it should be just like running on Unix.

==== MinGW/Msys ====
For MinGW/MSys, you need both the MSys DTK version of perl installed, and a native Windows perl - I have only tested with ActiveState perl, which I have found to be rock solid. You need to run the main buildfarm script using the MSYS DTK perl, and the web transaction script using native Perl. that mean you need to change the first line of the run_web_txn.pl script so it reads something like:
#!/c/perl/bin/perl
You should make sure that the PATH is set in your config file to put the Native perl ahead of the MSys DTK perl.
It's a good idea to have a runbf.bat file that you can call from the Windows scheduler. Mine looks like this:
@echo off
setlocal
c:
cd \msys\1.0\bin
c:\msys\1.0\bin\sh.exe --login -c "cd bf && ./run_build.pl --verbose %1 >> bftask.out 2>&1"
Set up a non-privileged Windows user to run this jobs as. set up the buildfarm as above as that user. Then create scheduler jobs that call runbf.bat with an optional branch name argument.

==== Microsoft Visual C++ ====
For MSVC you need to edit the config file more extensively. Make sure the 'using_msvc' setting is on. Also, there is a section of the file specially for MSVC builds. As with MinGW, you need a native Windows perl installed. It appears that Windows Git does not like to clone local repositories specified with forward slashes (this is pretty horrible - almost all Windows programs are quite happy with forward slashes. Make sure you specify the repository using backslashes or weird things will happen. Again, you will need a runbf.bat file for the windows scheduler. Mine looks like this:
@echo off
c:
cd \prog\bf
c:\perl\bin\perl run_build.pl --verbose %1 %2 %3 %4 >> bfout.txt
You will also need a tar command capable of bundling up the logs to send to the server. The best one I have found for use on Windows is bsdtar, part of the libarchive collection at http://sourceforge.net/projects/gnuwin32/files/. This is also a good place to get many of the libraries you need for optional pieces of MSVC and MinGW builds.

PostgreSQL Buildfarm Howto

2010-05-29T18:55:46Z

Mastermind: some minor copyediting on the buildfarm howto

PostgreSQL BuildFarm is a distributed build system designed to detect
build failures on a large collection of platforms and configurations.
This software is written in Perl. If you're not comfortable with Perl
then you possibly don't want to run this, even though the only adjustment
you should ever need is to the config file (which is also Perl).

=== Get the Software ===
Download from: [http://pgfoundry.org/frs/?group_id=1000040 pgFoundry]
Unpack it and put it somewhere. You can put the config file in a different
place from the run_build.pl script if you want to, but the
simplest thing is to put it in the same place. Decide which user you will run
the script as - it must be a user who can run the PostgreSQL server programs (on Unix
that means it must *not* run as root). Do everything else here as that user.

=== Set up a base git mirror that all your branches will pull from. ===
Most buildfarm members run on more than one branch, and if you do it's good practice to set up
a mirror on the buildfarm machine and then just clone that for each branch. As of this writing there are two suitable public git repositories:
* git://git.postgresql.org/git/postgresql.git
* git://github.com/oicu/pg-cvs-mirror.git
The first is the community repository, and is kept very up to date. Unfortunately it is broken on
branches earlier then REL8_3_STABLE. The second repository is similar to the first but is not broken on any of the live branches (as of the current writing). When the PostgreSQL project finally moves to using Git, currently expect to be around August 2010, both of these will become redundant. To set up a mirror, do something like this:
git clone --mirror git://github.com/oicu/pg-cvs-mirror.git pgsql-base.git
When that is done, add an entry to your crontab to keep it up to date, something like:
20,50 * * * * cd /path/to/pgsql-base.git && git fetch -q

=== Create a directory where builds will run. ===
This should be dedicated to
the use of the build farm. Make sure there's plenty of space - on my
machine each branch can use up to about 700Mb during a build. You can use the
directory where the script lives, or a subdirectory of it, or a completely
different directory.

=== Edit the build-farm.conf file ===
Put the location of the directory you just
created in the config variable "build_root". Set the "scm" to "git" and the "scmrepo"
to the path to your git mirror. If you are not using the community git repo, set the "scm_url" to
point to where to find a givven git commit on the web. e.g. for my mirror on github, the scm_url should be <i>http://github.com/oicu.pg-cvs-mirror/commit/</i> (Don't forget the trailing "/".)
Adjust the config variables
"make", "config_opts", and (if you don't use ccache)
"config_env" to suit your environment, and to choose which optional postgres
coniguration options you want to build with. You should not need to adjust any other variables.
Check that you didn't screw things up by running "perl -cw build-farm.conf".

=== Change the shebang line in the run_build script. ===
If the path to your perl
installation isn't "/usr/bin/perl", edit the #! line in run_build.pl so it is correct.
This is the ONLY line in that file you should ever need to edit.

=== Check that required perl modules are present. ===
Run "perl -cw run_build.pl".
If you get errors about missing perl modules you will need to install them.
Most of the required modules are standard modules in any perl
distribution.. The rest are all standard CPAN modules, and available either from there
or from your OS distribution. When you don't get an error any more, run the same test on
run_web_txn.pl. When all is clear you are ready to start testing.

=== Run in test mode. ===
With a PATH that matches what you will have when running from cron, run
the script in no-send, no-status, verbose mode. Something like this:
./run_build.pl --nosend --nostatus --verbose
and watch the fun begin. If this results in failures because it can't
find some executables (especially gmake and git), you might need to change
the config file again, this time changing the "build_env" with another
setting something like:
PATH => "/usr/local/bin:$ENV{PATH}",
Also, if you put the config file somewhere else, you will need to use
the --config=/path/to/build-farm.conf option.

=== Test running from cron ===
When you have that running, it's time to try with cron.
Put a line in your crontab that looks something like this:
43 * * * * cd /location/of/run_build.pl/ && ./run_build.pl --nosend --verbose
Again, add the --config option if needed. Notice that this time we didn't
specify --nostatus. That means that (after the first run) the script won't
do any build work unless the Git repo has changed. Check that your cron
job runs (it should email you the results, unless you tell it to send them
elsewhere).

=== Choose which branches you want to build ===
By default run_build.pl builds the HEAD branch. If you want to
build other branches, you can do so by specifying the name on the commandline,
e.g.
run_build.pl REL8_4_STABLE
so, once you have HEAD working, remove the --verbose flag from your crontab,
and add extra cron lines for each branch you want to build regularly.
You could have something like this:
6 * * * * cd /home/andrew/buildfarm && ./run_build.pl --nosend
30 4 * * * cd /home/andrew/buildfarm && ./run_build.pl --nosend REL8_1_STABLE

=== Register your new buildfarm member. ===
Once this is all running happily, you can register to upload your
results to the central server. Registration can be done on the buildfarm server
at http://www.pgbuildfarm.org/register.html. When you receive your approval by
email, you will edit the "animal" and "secret" lines in your config file,
remove the --nosend flags, and you are done.

=== Bugs ===
Please file bug reports on the tracker at [http://pgfoundry.org/tracker/?atid=238&group_id=1000040&func=browse | pgFoundry ]

=== Running on Windows ===
There are three build environments for Windows: Cygwin, MinGW/MSys, and Microsoft Visual C++. The buildfarm can run with each of these environments. This section discusses requirements for the buildfarm, rather than requirements for building on Windows, which are covered elsewhere.

==== Cygwin ====
There is almost nothing extra to be done for Cygwin. You need to make sure that cygserver is running, and you should set MAX_CONNECTIONS=>3 and CYGWIN=>'server' in the build_env stanza of the buildfarm config. Other than that it should be just like running on Unix.

==== MinGW/Msys ====
For MinGW/MSys, you need both the MSys DTK version of perl installed, and a native Windows perl - I have only tested with ActiveState perl, which I have found to be rock solid. You need to run the main buildfarm script using the MSYS DTK perl, and the web transaction script using native Perl. that mean you need to change the first line of the run_web_txn.pl script so it reads something like:
#!/c/perl/bin/perl
You should make sure that the PATH is set in your config file to put the Native perl ahead of the MSys DTK perl.
It's a good idea to have a runbf.bat file that you can call from the Windows scheduler. Mine looks like this:
@echo off
setlocal
c:
cd \msys\1.0\bin
c:\msys\1.0\bin\sh.exe --login -c "cd bf && ./run_build.pl --verbose %1 >> bftask.out 2>&1"
Set up a non-privileged Windows user to run this jobs as. set up the buildfarm as above as that user. Then create scheduler jobs that call runbf.bat with an optional branch name argument.

==== Microsoft Visual C++ ====
For MSVC you need to edit the config file more extensively. Make sure the 'using_msvc' setting is on. Also, there is a section of the file specially for MSVC builds. As with MinGW, you need a native Windows perl installed. It appears that Windows Git does not like to clone local repositories specified with forward slashes (this is pretty horrible - almost all Windows programs are quite happy with forward slashes. Make sure you specify the repository using backslashes or weird things will happen. Again, you will need a runbf.bat file for the windows scheduler. Mine looks like this:
@echo off
c:
cd \prog\bf
c:\perl\bin\perl run_build.pl --verbose %1 %2 %3 %4 >> bfout.txt
You will also need a tar command capable of bundling up the logs to send to the server. The best one I have found for use on Windows is bsdtar, part of the libarchive collection at http://sourceforge.net/projects/gnuwin32/files/. This is also a good place to get many of the libraries you need for optional pieces of MSVC and MinGW builds.

PgCon 2010 Developer Meeting

2010-05-20T14:27:22Z

Mastermind: s/Canova/Conova

A meeting of the most active PostgreSQL developers and senior figures from PostgreSQL-developer-sponsoring companies is being planned for Wednesday 19th May, 2010 near the University of Ottawa, prior to pgCon 2010. In order to keep the numbers manageable, this meeting is '''by invitation only'''. Unfortunately it is quite possible that we've overlooked important code developers during the planning of the event - if you feel you fall into this category and would like to attend, please contact Dave Page (dpage@pgadmin.org).

This is a PostgreSQL Community event. Room and lunch sponsored by EnterpriseDB. Other companies sponsored attendance for the their developers.

== Actions ==

* Josh & Selena will '''track open items''' and make sure they get listed or tracked and resolved.
* Selena to '''get reviewers to do a review fest June 15'''
* '''Branch''' on July 1, CF July 15.
* '''Announce a plan''' for next development schedule.
* '''No more branching''' for alphas.
* Stephen's '''intern to develop PerformanceFarm application'''. Will need help from Dunstan/Drake etc.
* Kaigai, Stephen, Smith, etc. to get together at pgCon and hash out some more security provider issues.
* Magnus to set up git environment emulator.
* Andrew to publish checklist of how to set up your Git
* '''Move to Git August 17-20''': Magnus, Haas, Dunstan. Frost will be out.
* Koichi to '''extract patch from PostgresXC for snapshot cloning''' and submit.
* Koichi to '''come up with proposed patch design for XID feed'''
* Develop '''specification for commit sequence / LSN data'''
* '''[[DDL Triggers]] Wiki page to be updated''' with spec by Jan, Greg M, et al
* Dimitri to do '''patch (regarding extensions..)''' More detail?
* EDB '''to decide on opening code''' or not for SQL/MED
* '''Review Itagaki's git repo code''': Heikki, Peter SQL/MED
* '''Itagaki to keep working on API''' -- what about Peter? SQL/MED
* '''Document what the plan is to do a conversion upgrade''' (Greg Smith) -- pg_update
* '''Copy Zdenek's code''' (Greg Smith) related to pg_update

== Time & Location ==

The meeting will be from 9AM to 5PM, and will be in the O'Connor room at:

Arc The Hotel
140 Slater Street
Ottawa
Ontario
K1P 5H6

[http://maps.google.ca/maps?f=q&source=s_q&hl=en&geocode=&q=ARC+THE.HOTEL+|+140++Slater+Street,+Ottawa,+Ontario,+K1P+5H6&sll=49.891235,-97.15369&sspn=45.043582,78.486328&ie=UTF8&hq=ARC+THE.HOTEL+|&hnear=140+Slater+St,+Ottawa,+ON&z=16&iwloc=A Google Maps]

Food and drink will be provided throughout the day.

== Invitees ==

The following people have RSVPed to the meeting:

* Oleg Bartunov
* Josh Berkus
* Joe Conway
* Jeff Davis
* Selena Deckelmann
* Andrew Dunstan
* David Fetter
* Dimitri Fontaine
* Marc Fournier
* Stephen Frost
* Magnus Hagander
* Robert Haas
* Tatsuo Ishii
* Takahiro Itagaki
* KaiGai Kohei
* Marko Kreen
* Tom Lane
* Heikki Linnakangas
* Michael Meskes
* Bruce Momjian
* Dave Page
* Teodor Sigaev
* Greg Sabino Mullane
* Greg Smith
* Greg Stark
* Koichi Suzuki
* Joshua Tolley
* Robert Treat
* Jan Wieck

== Agenda ==

{| border="1" cellpadding="4" cellspacing="0"
!Time
!Item
!Presenter
|- style="font-style:italic;background-color:lightgray;"
|09:00
|Tea, coffee upon arrival
|
|-
|09:15 - 09:25
|Welcome and introductions
|Dave Page
|-
|09:25 - 09:45
|Review of the 9.0 development process
|Dave Page
|-
|09:45 - 10:35
|Development Priorities for 9.1: General discussion
|Josh Berkus
|-
|10:35 - 10:45
|9.1 Development timeline
|Robert Treat
|- style="font-style:italic;background-color:lightgray;"
|10:45 - 11:00
|Coffee break
|
|-
|11:00 - 11:15
|Performance QA/Performance Farm planning update
|Greg Smith
|-
|11:15 - 11:50
|Advanced access control features [[:Image:Pgcon2010-dev-security.pdf|(Slides)]]
* Steps to support [[ESP|external security providers]]
* [[RLS#Issues|Issues]] of row-level access control
|KaiGai Kohei
|-
|11:50 - 12:30
|CVS to GIT: The finale?
|Dave Page
|- style="font-style:italic;background-color:lightgray;"
|12:30 - 13:30
|Lunch
|
|-
|13:30 - 13:55
|[[ClusterFeatures#Export_snapshots_to_other_sessions|Snapshot Cloning]]
|Koichi Suzuki
|-
|13:55 - 14:20
|[[ClusterFeatures#XID_feed|XID feed for clones]]
|Koichi Suzuki
|-
|14:20 - 14:45
|[[ClusterFeatures#Modification_trigger_into_core_.2F_Generalized_Data_Queue|General Modification Queue]]
|Itagaki Takahiro, Jan Wieck, Marko Kreen
|-
|14:45 - 15:10
|[[ClusterFeatures#DDL_Triggers|DDL "triggers"]]
|Jan Wieck
|- style="font-style:italic;background-color:lightgray;"
|15:10 - 15:25
|Tea break
|
|-
|15:25 - 15:55
|[[SQL/MED]] [[:Image:Pgcon2010-dev-sqlmed.pdf|(Slides from Heikki)]]
* Including: [[ClusterFeatures#Function_scan_push-down|function scan push-down]]
|Itagaki Takahiro
|-
|15:55 - 16:20
|Status report on Modules [[:Image:Pgcon2010-dev-extensions.pdf|(Slides)]]
|Dimitri Fontaine
|-
|16:20 - 16:45
|In-place upgrade with pg_migrator progress
|Bruce Momjian
|-
|16:45 - 17:00
|Any other business
|Dave Page
|- style="font-style:italic;background-color:lightgray;"
|17:00
|Finish
|
|}

== Minutes ==

= 2010 PostgreSQL Developer Meeting =

Ottawa, Canada

Present: Tatsuo Ishii, Andrew Dunstan, Bruce Momjian, David Fetter, Jeff Davis, Itagaki Takahiro, Koichi Suzuki, Josh Berkus, Dave Page, Dimitri Fontaine, Marko Kreen, Michael Meskes, Joe Conway, Josh Tolley, Greg Sabino-Mullaine, Selena Deckelman, Stephen Frost, Robert Treat, Robert Haas, Magnus Hagander, Kohei Kaigai, Heikki Linnakangas, Tom Lane, Jam Wieck, Oleg Bartunov, Teodor Sigaev, Marc Fournier, Greg Smith, Greg Stark, Peter Eisentraut (via Skype)

== Review of The 9.0 Development Process ==

How did the commitfest work? Do we feel that the process worked in general, do we like Robert's CF application? What other parts of the process should we improve?

David Fetter commented that the writable CTE patch went through more than one CF without adequate feedback, and the patch got rejected. Should we not allow things to be bumped, or not bumped twice? Still listed as open on November Commitfest. RH thinks feedback was provided but it might not have been very clear. It ''was'' reviewed more than once. RT: maybe we shouldn't be so quick to bump people in the last CF. Writeable CTE wasn't bumped until Feb. 10. Part of the issue is that it's a very complicated patch.

JB feels that integration/testing needs to be more structured. Still amorphous. If we had more structure, maybe it would go faster. RH we had a lot of open items, we closed them an released Beta1. Agrees that we need more concrete critera. BMomj: we end up with a pile of really hard problems which we don't know how to fix. Even now can't fix max_standby_delay. Needs to be a fire under someone. Open items list is a big win, but doesn't show the scope of the problem. Didn't have anything on open items list until this AM for Beta. Need to reconstitute list.

If stuff is on the open items list it stops release. DF: maybe we should have ratings of complex/not? Perhaps we need release manager to keep up on open items etc.? Or Beta manager. Not everyone knows what every open item is. Someone should track the list and see status. Need list to know what to work on. JB would like to put stuff on the open items list. If there's a thread on hackers put it on the list.

How do we get all the big patches in the first commitfest or second instead of last? Assumes people are working while releasing. Why didn't HS get into first commitfest. Post-CF, prerelease is long and delays development, people take a vacation for 6 months. Also the CF reviews were not very good for big patches. CFs worked well for small/medium patches. But for big patches not so great. KNNGiST and WriteableCTE not so great. HS at least didn't get into last commitfest.

How much of a problem is this issue going to be for 9.1? Do we have anything that large? Synchronous Replication. SQL/MED?

Josh & Selena will track open items and make sure they get listed or tracked and resolved.

== Priorities for 9.1 ==

See [[PgCon_2010_Developer_Meeting#Development_Priorities_for_9.1|priority grid]] below.

== Timeline for 9.1 ==

Treat: Release in July, have an immediate commitfest of pending stuff. Will we release in July? If we're late, do we want to drop a commitfest and have shorter cycle? Maybe the development cycle should go, even if the release is delayed? Lane doesn't think we have enough manpower for that.

Issue is that people are waiting 6 months to resume development. Are there enough reviewers, though? Maybe we could have a reviewfest. Haas thinks that we have manpower. Berkus likes the idea of a reviewfest, new people. Haas says that we could commit stuff or at least put it "pending commit". Smith says that pruning patches would be valuable. What's the main bottleneck of people? Maybe Kevin could run it.

We would need to branch first. Which would involve backpatching. Branch on July 1, first CF on July 15? Or 15 and August 1? Tom Lane: if we're not close to releaseable by July 1, then it's not feasible. Frost would like to have reviewfest in June. We could ask for reviews right now. RRRs need more direction. Selena will help.

In the future, do we want to start earlier? We should get more people to help with getting to beta. Get people on open items list. Put it on the commitfest app? Magnus: but that makes it closer to a bug tracker. Haas: cycle of work is different for open items. No, will use wiki instead. Next year we'll have an open items app.

Doing early branching will also help with bitrot. And will help with people's work schedules.

Plan is to start 9.1 development on July 15, and only delay if things blow up.

Alpha releases unanimously good. We might want to branch them differently. Downloads weren't huge, 10s or maybe 100 per alpha. But practice found issues with packaging, build scripts, etc. Maybe we shouldn't create branches for them, though. We should just tag it. We just wanted it to say the right name. This is probably fixed. So, for 9.1 we'll have a patch for the tarball and not a branch. Discussion of checkout/tag/branch detailed ensued.

CFs need to have enough reviewers. Need to recruit more? Need to make it clear what's in it for reviewers. Reviewers should be nominated for minor contributors.

Actions:
* Selena to get reviewers to start now.
* Branch on July 1, CF July 15.
* Announce as plan for schedule.
* No more branching for alphas.

== Performance QA/Performance Farm ==

Last year we took this as an issue at the meeting. Holdup was pgBench needed overhaul; results were useless on Linux. New pgBench should resolve those problems. Got something in pgBench tools which tries to figure out number of threads. Other thing which has been moving along well is benchfarm, and how should systems be set up to give reasonable performance. Greenplum has nice utility called gperftest, people need to test hardware before running pgbench. Nobody will let us benchmark high-end machines and talk about the results. Smith has some new high-end machines to test performance results.

Smith: we are ready to write a spec for a performancefarm client. Need to build client for this. Frost has an intern to work on Postgres stuff will be working on performance farm client. Will be working for 8 weeks.

Performancefarm also needs to run a battery of individual operations for performance regressions. Also needs to run a quick hardware/OS test for comparability. Need a general framework; maybe we'll eventually add DW test or TPCH.

Why do we keep the same dependancy restrictions as buildfarm? It's easier to get clients that way. If we can tell people that they can just add the PerformanceFarm to the buildfarm, it's easier. Will go to assembled tool very soon. Data collection will start with 9.0 because of old pgbench. Biggest thing is to notice if someone's patch torpedoes performance.

Propose that machines for the PerformanceFarm be named after plants. ;-)

What about replication performance? Too big to take over.

Actions: Stephen's intern to develop PerformanceFarm application. Will need help from Dunstan/Drake etc.

== Advanced Security Features ==

KaiGai's Presentation <link?>

We try to load something externally to make access control decisions. Row-level access controls have a number of issues.

PostgreSQL currently has logic & access controls in the same place. (1) rework external check using same flow. (2) add label support. (3) add SELinux support. New method will have clear separation between Postgres and SELinux, possibly using a loadable module.

Rework of access controls needs to do all of the access control checks at once instead of one at a time with query in between. Need to do one object at a time because otherwise it's too big. That way patches are only 200-500 lines each.

Finally, add security labels to objects.

The concern with the rework was that moving all of the security checks into a separate area was that that area needed to have knowledge about everything. Haas: need to provide a clean interface to security providers, but not by changing huge amounts of code. Heikki: it's not that big, it's fairly mechanical.

Currently we check some basic things (like does the table exist) and later we check fine-grained permissions. Completely isolating it not possible. Locks for one thing. Also it's difficult to have a clean API because the API needs to know about everything. Kaigai says that generalized interface isn't necessary, Linux has had to add to the API with each new security provider.

Why can't we put calls in the current aclcheck? Too low-level, don't pass enough information to them. We could pass more. But if we have the OID, we can look up all of the class information. Right now we have duplicate permissions checks all over the code. And the checks we need to do are not necessarily the same checks which SE wants to do.

Smith: what users want isn't necessarily what we have in the patch. Maybe we should just build a subset of functionality, a lot of people don't care about DDL etc. We could implement only SELECT security, it would make the patch more digestible. All permissions checks for SELECT are all in one place. Or DML only.

Does the information provided supply enough? It has to be because it's the first stage. It's basically the information the user entered.

Is DML-only enough? Will it leak? Of course. Anyway, it's useful simplication. Smith says 95% of use cases are solved by that. Table discussion of all of the ACL checks. Kaigai says that checks are the same for DML and DDL, but others do not agree.

Security Label discussion. Access control decisions operated by Subject, Target, Action. Label replaces Target. Syntax introduced, ALTER ... SET WITH SECURITY LABEL, SECURITY LABEL TO label. Simplified suggestion, just add seclabel[] text to catalogs. But wastes space and hurts peformance.

Should SELinux be in core or be loadable module?

Actions: Kaigai, Stephen, Smith, etc. to get together at pgCon and hash out some more issues.

== CVS to GIT ==

Its probably clear that we should change to a new VCS, and it should be GIT. No disagreement.

What are the gating factors to moving now? Let's make a decision to do it, and when and we'll fix the issues. Problem with buildfarm has been solved. Buildfarm now runs git. Building Git on any older platform is impossible; bad make files. Getting all buildfarm members running Git wouldn't be possible, but we can run CVS mirror for older ones.

We have a checklist on the wiki already for switching.

Most buildfarm members will run either; it's a config item. We'll track which ones are using the emulator.

Building older versions may have issues to build identically. Magnus claims that it's been fixed. How much do we care about old tags? There are still a couple of bad files but they're minor. Do we still have old issues with CVS? Marc says they're fixed, shouldn't show up in Git history.

Are commit e-mails an issue? No. But e-mails will look different. Tom wants them to just work the same.

We don't need to solve technical issues here. Just pick a date. We'll know when we're doing it and that everything will suck for a month afterwards. Will need to be a low-stress time for the project, between commitfests. Tom isn't sure how to apply commits across multiple branches. Discussion of Git details hashed out.

Two issues: sheer space usage. Second, management of commits. But these are not serious problems. Andrew has checklist. Will need to test stuff and decide how to do specific stuff. Suggestion on date: after 2nd commitfest. No, halfway after first commitfest. No, immediately after first commitfest ... August 20th or similar.

We will have git super-master which synchs to git.postgresql.org. Can do receive hooks. Have we considered using github? Github should not be canonical source, in case they go away. Can't do postcommit hooks on Github. People can just do both. Forking Postgres repo puts you near their limit. Put off Github questions.

Issue: what about the name? People will need to reclone, will be part of suckitude. Rename old repo and create new repo. Where will secret master repo be? Maybe Conova.

Mapping usernames onto e-mail addresses could be a pain. Maybe we should standardized onto committer@postgresql.org. Committers should pick names before conversion.

Discussion about commit messages, merges, commits, etc. ensued.

Action:
* Magnus to set up emulator.
* Andrew to publish checklist of how to set up your Git
* Move to Git August 17-20: Magnus, Haas, Dunstan. Frost will be out.

== Lunch ==

== Clustering ==

=== Snapshot Cloning ===

Koichi: had meeting in Tokyo, and make a list of core APIs which clustering projects could use. Snapshot cloning is one such, plus it's useful for parallel query and parallel pg_dump. First use snapshot cloning to enforce consistent view of the database. Has already implemented this for PostgresXC. The same thing could be applicable for single PostgreSQL. It is a very simple implementation, and should not produce resource conflicts.

For parallel pg_restore, maybe snapshot cloning will not be sufficient. Cloning the snapshot for read-only transactions is simple, not for write transactions.

Smith: Using this for parallel query also works for read-only cloning.

Very useful for dumping partitioned tables, with one backend for each partition.

Added API to libpq. But shouldn't this be a server-side command? For cluster usage, it was useful for it to be in libpq. RH: one idea is a function we could call, and the shared snapshot would use a "cookie". Joachim W. wrote a patch with publish/subscribe. Needs to be all server-side.

Tom has suggestion for simpler implementation, without locks. That is, you just need to have same snapshot start, not shared snapshot. Snapshot would die once the original transaction was gone. Koichi: this is not a problem.

Tom: maybe we could just use a prepared transaction, which would keep the snapshot valid. Proposing to begin with read-only implementation.

Action: Koichi to extract patch from PostgresXC and submit.

== XID Feed ==

PostgresXC needs to have a transaction run on multiple servers in the same cluster. The XID is needed so that you can have the same transactions. Will also be useful for parallel write operation, but that's really complicated. Parallel backend needs to be assigned same XID, but locks, resource conflicts.

Heikki: let's start with parallel read queries.

JB: parallel write on one server is a different feature than XID feed for clustering.

Multiple backends share the same XID so they can share the same snapshot. If you're doing a multimaster update across multiple servers so you can maintain serialization. Stark explains multi-server deadlock situation.

The XID is not the issue, it's the commit order. But communicating the xids means that you don't need to communicate more data to the servers. Just maintaining transaction IDs isn't enough, we need to maintain commit/abort info. If you want a snapshot which is valid on both nodes, you'd have to lock the procarray on both. You'd have to have a single global transaction manager controlling commits.

What is the core feature here? You might want to make a specific instance of Postgres the global transaction manager. Or you might make one postgres a consumer of snapshots. Heikki: you could interrogate each node about what transactions were running at the time of the snapshot. Some discussion without agreement.

Koichi explains how snapshots are distributed in PostgresXC, they receive them with XID. There's no negotiation between nodes. What stability would this affect with core Postgres? Vacuum and analyze need their own GXID.

What is the feature: getting XID and Snapshot from PostgreSQL. Is this useful for core Postgres? Does it work for other cluster systems other than PostgresXC. Would be useful for all synchronous multi-master replication. Like Postgres-R. Or any distributed databases. Should be done as a "hook". Not really different from two-phase commit, but not testable without an external manager, which is the main problem. How could you test it?

What other things do you need? What other hooks would we need in core to support GTM and other clustering functionality? If we had SQL/MED working, you could export XIDs to remote tables. But we don't have that yet.

A hook will be fine.

Action: Koichi to come up with proposed patch design

=== General Modification Queue ===

Marko: one use case is transactional que. Have some sample imentations in pgQ and Slony. Two different stragies: Slony/Londiste, and Josh wants to replicate data to external non-PostgreSQL tables. Josh is mainly concerned about write overhead, but no way around WAL.

What is not solved by current LISTEN/NOTIFY? What this has is potential for really improving. Both Slony and pgQ rely on being able to filter out blocks of events and serialized sequence of individual events. Problem is eventID sequence number cannot be cached, that causes painful overhead. Both systems come up with insert/update/delete statements which go by index scan.

If we can support general functions where a trigger can hand in old and new tuples and the receiver can get something which allows it to pull new data. Seems like commit order is the issue. Why do you need a sequence which can't be cached? If you knew what order they committed ... you wouldn't need a global counter. Jan isn't sure this makes sense for core because of lack of version independance.

If you had a stream of commit information, you'd just have to buffer it. But that could work. The real missing piece is a commit ordering stamp, which the database should supply for you. This was a requirement of Postgres-R as well, they need to know what order to apply the writeset in.

We could use the LSN of the commit record as that number. In the CLOG, for a range of XIDs, we have some LSNs. But it's not enough information. It sounds like all that's really needed is to have a way to grab LSN numbers. Maybe write it to a separate file.

Commit-order table would need to be truncated. The clients have to send message about being done with it. Do we want to call gettimeofday while holding walinsertlock? Tom: we already are, but it's not exact enough. LSN plus approximate timestamp would give you order.

Clients would need to look and say grab all transactions between one LSN and another.

Action:
* Develop specification for commit sequence / LSN data

=== DDL Triggers ===

Jan: it's a feature we've been missing for at least a decade. Jan starting to work on it, but DDL code is very messy. It's in tcop_utility.c function process_utility. The mess is that while the function gets a query string some calls don't put a real query string in there.

Purposes include enforcement of complex CREATE requirements. Also replicating DDL to replicas. Wouldn't you like it better if the data were passed to the trigger using some kind of structured data rather than a query string. Take node structure of utility statement and create query string which can be passed, as well as passing node structure using nodetostring.

We haven't exposed nodetostring because it's not a stable API. But generally changes there indicate changes in features. But if we could give the trigger an object name. Maybe we could pass before-and-after snapshots.

How do Oracle and other systems get this data?

Also there's an issue that some utility statements call other utility statements.

Nodetostring exposure was also vetoed for other reasons. Slony and other systems can take a tree instead. Maybe we should already have a utility function. We already theoretically have a hook, but it's not being used. And also still a problem with recursive calls.

pgAdmin wants a notification for changes. Would need some notification with data about object changed. But just object changed would be enough. We could also build up a set of events for DDL changes over time based on the tree ... we can start with just objectype and objectID. And type of modification: create, drop, alter.

ProcessUtilityHook is there, but the problem is how it's exposed to the user. Hooks aren't used consistently and you don't know who has set it in what modules. Several people are already using it. Ordering becomes a problem. People don't want to use the hook.

We also want a userspace implementation. Like maybe a trigger.

Action:
* Wiki page to be updated with spec by Jan et. all.

== Status Report on Modules ==

Slides from Dimitri

Many issues and topics. Talking today about dump/reload support. If you dump and restore, you don't want to restore objects. We want to support any source language. We want to support custom GUCs and versions in extensions. We also want upgrading factilities.

We are not going to talk about schema. We are not going to talk about souce level packaging, ACLs, PGAN or OS packaging and distribution. Example of extensions/foo/control. Should be in user/share. Control file will have name, version, custom_variable_classes.

Then you can just do install extension foo, drop extension foo. pg_restore would call install extension foo and not its objects.

Need dependancies on extensionID in pg_depends so we know what belongs to the extension.

Used name = value because we already know how to parse them in control file. pg_dump will be easy, we will know how to exclude based on dependancies. uninstall.sql files will be replaced by this.

What do we do about user-modifiable tables which are associated with a module? This is similar to how debian deals with config files. Or we could allow install files have items which aren't tracked as part of the module, and pg_restore would need to know about that.

Should extensions have different versions or different names per version? The install script is just a sql file, you can add a DO script. Debian handles this by checking if the configuration is the default and replacing it, or failing over to the user afterwards.

Need license information in the control file.

We probably just need to punt configuration tables to version 2.

Will this help pg_upgrade? Maybe. Right now you have to migrate shared libs yourself. Will fix some cases.

Action:
* Dimitri to do patch

== SQL/MED ==

Slides by Heikki.

Heikki: in EDBAS, we already have foriegn tables. CREATE FOREIGN TABLES syntax. EDB has libpq, Oracle and ODBC. Shows slide with join plan; currently materialize locally.

Have to decide what plans you can push to the remote database. Not all remote sources can handle all structures, including functions, joins etc. Even between PostgreSQL ruleutils.c is different for each version.

Proposed FDW planner API. Pass parse tree, needs to say what it can take. How do we not duplicate the entire planner in the API. EnterpriseDB has been working on this but company has not committed to contributing it.

Jan mentioned that at least a wrapper has to take a scan.

Itagaki: didn't know EDB was also working on SQL/MED. Code is probably completely different. There's four issues: any features it should consider about. Currently considering dbLink and COPY FROM. Maybe there should be other features, like GDQ.

Josh: what about PL/proxy? SQL/MED should support the functionality of PL/proxy.

What is the best design to support access methods for tables? Postgres AMs for indexes, we need AMs for FDWs. Update is a problem, may start with select and insert.

How to push WHERE conditions to FDW? Itagaki's WIP code uses internal tree, requires C code in FDW to parse. Might be unstable for that reason. External server might not be SQL server, so passing SQL isn't that useful.

FDW vs. SRF ... can we merge these somehow? Current implementation of functionscan is to materialize. We didn't do value-per-call because it was difficult with PL/pgSQL. So we just materialized it.

Heikki suggested that we don't use the FDW API from the SQL committee because nobody uses it. Supplies function for reaching into planner but can't imagine how it would work. EnterpriseDB implements pipeline.

Also, an issue is cost estimation. How do we know how much it would cost. Statistics on remote tables? We could store them. It would also be nice to have joins take place on the remote server, but that's version 2 or 3.

Also what about indexes on the remote server. One implementation in Japan has CREATE FOREIGN INDEX. Creating definitions locally of remote schema are very useful. DB2 implemented this and had commands to define foreign objects.

Maybe we don't need to be really smart about this in the first version. But people are asking for this. Pass whole query to remote server. Wouldn't work for joins, but would work for union query. Defining an index on a FDW doesn't make much sense since we don't know what the costs are like over there. We should just have a function in the API.

How would we recognize that we want to do the join on the remote server. We just need costs from the FDW. But we could also keep them in pg_stats. FDW might be used to access complex database like Infobright or Bigtable.

Would EDB contribute a patch? Or just the rights for Heikki to steal bits? Patch from EDBAS would not work. Does the EDB patch help Itatgaki? EDB might get Itagaki access to the code.

Action:
* EDB to decide on opening code or not
* Review Itagaki's git repo code: Heikki, Peter
* Itagaki to keep working on API -- what about Peter?

== pg_migrator ==

Bruce: Just fixed a but in pg_upgrade for XID wraparound. Added docs. Migrator tries to rebuild a plane in the air. Bruce feels like he has a swiss army knife with pg_upgrade. Issue with FrozenXIDs in template0 fixed. Still a work in progress, which is why it's in contrib, still a work in progress but bugs are fixable.

Will still have issues with page format, binary format changes. Haven't had those for a while, may not need them, and a dump & restore every 4-5 years is an improvement. Bunches of people have used it to migrate. The tool makes sure that it doesn't corrupt your data, it goes back if it hits an error.

Stark: In the past we've had a chicken-and-egg issue if people wanted to make changes to the data format, we'd need a conversion function. And there's no hooks in pg_migrator. Could slow down the pace of adding features. We should add the functionality to do the conversion now.

pg_upgrade from EDB has hook for COPY mode for conversion. And then what's the point of pg_migrator? If you don't have to rebuild indexes. But a lot of times you'd have to. But to have it in place so that it's not a hurdle for a data change. If we're going to do that we need to do it for 9.1 early in the cycle.

Dump and reload is impossible for Smith's customers. page checksum thing is a good example. Read-on-conversion is a big performance hit. Background process to convert all old data.

Also issue around internal representation of data type change. We either have to convert it, or have versioned data types.

Is binary data conversion really faster? Read back one version, and convert while running. Something which can read one version level back and can convert is the only viable way. Would have a daemon to convert data. What about split pages, bigger page headers.

CRC would be a good test for this. It's a small patch but has a lot of common upgrade issues. And it would be only one patch so we could put it off for another version if we had to. Would like to get this started for 9.1. CRC requires dealing with the split pages issue.

Really tricky stuff includes changing indexing structure. Would need concurrent rebuild for unique indexes and primary keys. REINDEX concurrently was a deadlock concern.

What about writing? Convert-on-read.

Action:
* Document what the plan is to do a conversion upgrade (Greg Smith)
* Copy Zdenek's code (Greg Smith)

== Other Business ==

Treat: Mammoth Replicator into Core? Code has been BSD-licensed. Has features which don't exist in Hot Standby. Code is pretty big. Alvaro would say that it's not in great shape to contribute at this point.

Has log-based replication including per-table. Has its own logs, and has binary vs. SQL replay. Not trigger-based.

Real question is would we consider putting any replication solution into Core? Not until we've finished digesting HS/SR. Replication is one word for a dozen different solutions for 3 dozen problems. We've accepted one which solves some problems. Page things we should consider each case on its merits.

Question is what parts of Mammoth make sense to be in core. Bruce thinks that mammoth is so tied into the backend that we couldn't accept it. It's too complicated. It doesn't sound like Mammoth offers enough functionality to make it worth it.

Does mammoth need to be in core? It has grammar changes. We now have better ideas of what replication requirements are, we may have more commonalities in core in the future. Part of the reason have so many because we don't have one in Core.

We'd consider more replication in core, but maybe not Mammoth.

Action:
* None

== Other Business ==

Peter says we're almost compliant with SQL 2008. Is it of PR value to comply with the remaining random stuff? People don't think so.

What about Case Folding? We probably don't want to fix that. Wasn't on Peter's list, which is just features. Case Folding would break a lot of stuff. Thought Peter was already doing that with a couple of features per version.

Compliance is only of moderate value. Is there a point of implementing the features on Peter's list?

Summer of Code: how is it going?

Haas has concern. His student is working on Materialized Views. Has proposed a very basic implementation. Might not be able to do even that. We can fail people.

Selena just updated the open items on the mailing list. A lot of items were not closed on the mailing list.

What about max_standby_delay? Tom wants to go back to just a boolean. What about Tom's original proposal? Can't really do it. Tom wants to remove time dependancy. What are the issues with max_standby_delay? Idle time on the master uses up time on the standby. Plus NTP and keepalives and some other stuff.

Major discussion on max_standby_delay ensued.

== Development Priorities for 9.1 ==

{| border="1" cellpadding="4" cellspacing="0"
!Feature
!Developers
!Notes
|-
|MERGE/UPSERT/REPLACE
|GSoC with Greg Smith/Simon
|Issues with predicate locking
|-
|Synchronous replication
|Fujii/Zoltan/Simon
|Review by Heikki
|-
|Improve Hot Standby/Streaming Rep usability
|Simon/Fujii/Greg Smith
|Review by Josh Berkus
|-
|Snapshot cloning API
|Koichi
|Sample app is parallel pg_dump
|-
|Locale/encoding
|
|per column/per operator collation
|-
|User exposed predicate locking
|Simon
|Interaction with serialization
|-
|Serializable
|Kevin Grittner
|
|-
|pg_upgrade in core
|Bruce
|
|-
|External security provider
|KaiGai
|
|-
|Row-level security
|KaiGai
|
|-
|Writeable CTEs
|Marko Tiikkaja
|
|-
|SQL/MED
|Itagaki
|
|-
|Generalized inner-indexscan plans
|Tom Lane
|
|-
|Re(?)plan parameterized plans with actual parameter values
|Tom Lane
|
|-
|COPY as a FROM clause
|Andrew Dunstan
|
|-
|Pipelining/value per call for SRFs
|Joe Conway
|
|-
|Partitioning implementation
|Itagaki
|
|-
|Index only scans
|Heikki
|
|-
|Global temp/unlogged tables
|Robert Haas
|
|-
|Inner join removal
|Robert Haas
|
|-
|Extensions
|Dimitri
|
|-
|Range types
|Jeff Davis
|
|-
|Materialized views
|GSoC+Robert Haas
|
|-
|JSON data type
|GSoC
|
|-
|DDL Triggers
|Jan
|
|-
|Leaky view security
|
|
|-
|KNNGist
|Teodor
|
|-
|Performance farm
|Greg Smith
|
|-
|Git
|
|
|-
|PGAN
|David Wheeler
|
|}

[[Category:PostgreSQL Events]]

Performance QA Testing

2010-03-13T18:24:21Z

Mastermind: /* Datasets */

This page centralizes the efforts on performances QA testing: available hardware, available tools, continuous benchmarking effort...

The PostgreSQL Performance lab is being created to allow community members of the Open Source database [http://www.postgresql.org/ PostgreSQL] to have enterprise class hardware to test on.

The testing that will occur includes industry standard workloads such as OLTP, DSS and BI. Furthermore we will also use the hardware for other practical and customer oriented testing to improve scalability (processor utilization, i/o, load balancing, etc.) and managing large data sets (loading, backups, restores, replication, etc).

=== Donations ===

For donation inquiries, please contact [mailto:josh@postgresql.org Josh Berkus <josh @t postgresql.org>] and [mailto:jdrake@postgresql.org Joshua Drake <jdrake @t postgresql.org>].

=== Mailing List ===

There is a [http://lists.pgfoundry.org/mailman/listinfo/perflab-general mailing list] available to discuss administrative aspects of community equipment. Please continue to use the -hackers and -performance mailing lists for performance and technical discussions.

== QA platforms ==

* [[QA Platform hosted at Command Prompt]] - Portland, Oregon, USA
* [[QA Platform hosted at Open Wide (France)]]

== Tools ==

* Former OSDL work: [http://osdldbt.sourceforge.net/ Database Test Suite] and [http://crucible.svn.sourceforge.net/viewvc/crucible/ Web interface]
* [http://www.westnet.com/~gsmith/content/postgresql/pgbench-tools.htm pgbench-tools from Greg Smith]. See [[Regression Testing with pgbench]].
* [http://bristlecone.continuent.org/HomePage Bristlecone from Continuent]
* [http://tsung.erlang-projects.org/ Tsung load injector] allows to define sessions (containing queries and thinktime, etc) and replay them with very high concurrency setup. Can use many loading nodes at a time, multi OS support (written in [http://www.erlang.org/ erlang], extensible in this language)
* [http://dim.tapoueh.org/temp/tsung-plotter/ Tsung Ploter] plots several tsung runs onto the same graphs set, for easy comparing. Uses python and matplotlib.
* Tsung DBT2 Implementation (tsung module in erlang), WIP, to get published asap.

== Ideas ==

* look into [http://sysbench.sourceforge.net/ sysbench] - it has some issues with locking on postgresql but at least read-only it seems to work fine

* collecting all the various small samples and testcases posted over the last few years on -performance, -hackers & -bugs and put them into a test set

* consider doing tests using pgbench -M (simple|extended|prepared) to catch regressions in one of those modes

* resurrect Jan Wiecks tpc-w implementation available on [http://pgfoundry.org/projects/tpc-w-php/ pgfoundry]

* add full text search benchmarking by using [http://www.sigaev.ru/cvsweb/cvsweb.cgi/ftsbench/ ftsbench] from teodor

* XML benchmarking ?

* investigate [http://advogato.org/person/nconway/diary.html?start=21 QuickCheck] and http://advogato.org/person/nconway/diary/23.html

* Implement the [http://www.cs.umb.edu/~poneil/StarSchemaB.PDF Star Schema Benchmark].

== Datasets ==

Some public datasets that could be used to get realistic data for various kind of benchmarks:

* [http://www.freebase.com/docs/data_dumps Freebase] - Various wiki style data on places/people/things - ~600MB compressed
* [http://www.imdb.com/interfaces#plain IMDB] - the IMDB database - see also http://code.google.com/p/imbi/
* [http://www.data.gov/ ] - US federal government data collection see also [http://www.sunlightlabs.com/ sunlightlabs]
* [http://wiki.dbpedia.org/Downloads DBpedia] - wikipedia data export project
* [http://linux.dell.com/dvdstore/ Dell DVDstore] - Dells DVD Store context data
* [http://www.eoddata.com/ eoddata] - historic stock market data (requires registration - licence?)
* [http://www.transtats.bts.gov/Tables.asp?DB_ID=120&DB_Name=Airline%20On-Time%20Performance%20Data&DB_Short_Name=On-Time RITA] - Airline On-Time Performance Data
* [http://wiki.openstreetmap.org/wiki/Planet.osm Openstreetmap] - Openstreetmap source data

== Information ==
* [http://wiki.postgresql.org/wiki/Performance_Optimization In depth performance articles on PostgreSQL]
* [http://wiki.postgresql.org/wiki/HP_ProLiant_DL380_G5_Tuning_Guide DL380 Tuning Guide]
* [http://www.vimeo.com/channels/postgres Videos on Performance and other topics]
* [http://www.commandprompt.com/blogs/joshua_drake/2008/04/is_that_performance_i_smell_ext2_vs_ext3_on_50_spindles_testing_for_postgresql/ Performance measurements between load and filesystems (Linux)]

Todo

2010-02-25T06:55:18Z

Mastermind: add outbound interface binding to TODO

<div style="margin: 1ex 1em; float: right;">
__TOC__
</div>

This list contains '''all known PostgreSQL bugs and feature requests'''. If you would like to work on an item, please read the [[Developer FAQ]] first. There is also a [[Development_information|development information page]].

* {{TodoPending}} - marks ordinary, incomplete items
* {{TodoEasy}} - marks items that are easier to implement
* {{TodoDone}} - marks changes that are done, and will appear in the next major release

For help on editing this list, please see [[Talk:Todo]]. <b>Please do not add items here without discussion on the mailing list.</b>

<div style="padding: 1ex 4em;">
== Administration ==

{{TodoItem
|Allow administrators to cancel multi-statement idle transactions
|This allows locks to be released, but it is complex to report the cancellation back to the client.
* http://archives.postgresql.org/pgsql-hackers/2008-12/msg01340.php
* http://archives.postgresql.org/pgsql-hackers/2009-12/msg00441.php
}}

{{TodoItem
|Check for unreferenced table files created by transactions that were in-progress when the server terminated abruptly
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00096.php <nowiki>Removing unreferenced files</nowiki>]
}}

{{TodoItem
|Set proper permissions on non-system schemas during db creation
|Currently all schemas are owned by the super-user because they are copied from the template1 database. However, since all objects are inherited from the template database, it is not clear that setting schemas to the db owner is correct.}}

{{TodoItem
|Allow log_min_messages to be specified on a per-module basis
|This would allow administrators to see more detailed information from specific sections of the backend, e.g. checkpoints, autovacuum, etc. Another idea is to allow separate configuration files for each module, or allow arbitrary SET commands to be passed to them. See also [[Logging Brainstorm]].}}

{{TodoItem
|Simplify ability to create partitioned tables
|This would allow creation of partitioned tables without requiring creation of triggers or rules for INSERT/UPDATE/DELETE, and constraints for rapid partition selection. Options could include range and hash partition selection. See also [[Table partitioning]]
}}

{{TodoItem
|Allow auto-selection of partitioned tables for min/max() operations
|There was a patch on -hackers from July 2009, but it has not been merged: http://archives.postgresql.org/pgsql-hackers/2009-07/msg01115.php}}

{{TodoItemDone
|Allow more complex user/database default GUC settings
|Currently ALTER USER and ALTER DATABASE support per-user and per-database defaults. Consider adding per-user-and-database defaults so things like search_path can be defaulted for a specific user connecting to a specific database.
* [http://archives.postgresql.org/pgsql-hackers/2006-09/msg02345.php <nowiki>Re: Per-database search_path</nowiki>]
* http://archives.postgresql.org/message-id/20090811221921.GK16362@alvh.no-ip.org
}}

{{TodoItem
|Allow custom variables to appear in pg_settings()
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00850.php <nowiki>Re: count(*) performance improvement ideas</nowiki>]
}}

{{TodoItem
|Allow custom variable classes that can restrict who can set the values
|The common cases (POSTMASTER, SIGHUP, and SUSET) are already handled to some extent as of 8.4. Should we mark this DONE?
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg00911.php <nowiki>custom variable classes</nowiki>]
}}

{{TodoItem
|Implement the SQL standard mechanism whereby REVOKE ROLE revokes only the privilege granted by the invoking role, and not those granted by other roles
* [http://archives.postgresql.org/pgsql-bugs/2007-05/msg00010.php <nowiki>Re: Grantor name gets lost when grantor role dropped</nowiki>]
}}

{{TodoItem
|Improve server security options
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01875.php <nowiki>Re: [0/4] Proposal of SE-PostgreSQL patches</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00000.php <nowiki>Re: [0/4] Proposal of SE-PostgreSQL patches</nowiki>]
}}

{{TodoItem
|Prevent query cancel packets from being replayed by an attacker, especially when using SSL
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg00345.php <nowiki>Replay attack of query cancel</nowiki>]
}}

{{TodoItem
|Provide a way to query the log collector subprocess to determine what the currently active log file is
* [http://archives.postgresql.org/pgsql-general/2008-11/msg00418.php <nowiki>Current log files when rotating?</nowiki>]
}}

{{TodoItem
|Allow the client to authenticate the server in a Unix-domain socket connection, e.g., using SO_PEERCRED
* http://archives.postgresql.org/message-id/20090401173756.GB21229@svana.org
}}

{{TodoItemDone
|Allow the client to set an application_name to appear in pg_stat_activity
* http://archives.postgresql.org/message-id/407d949e0907161237r76ebd92av6836c6563d8a230e@mail.gmail.com
}}

{{TodoItemDone
|Allow server-side enforcement of password policies
|Password checks might include password complexity or non-reuse of passwords. This facility will require the client to send password creation/changes to the server in plain-text, not MD5.
* http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php
* http://archives.postgresql.org/pgsql-hackers/2009-10/msg00025.php
}}

{{TodoItem
|Allow custom daemons to be automatically stopped/started along postmaster
|This allows easier administration of daemons like user job schedulers or replication-related daemons.
* http://archives.postgresql.org/pgsql-hackers/2010-02/msg01701.php
}}

=== Configuration files ===
{{TodoSubsection}}

{{TodoItem
|Allow pg_hba.conf to specify host names along with IP addresses
|Host name lookup could occur when the postmaster reads the pg_hba.conf file, or when the backend starts. Another solution would be to reverse lookup the connection IP and check that hostname against the host names in pg_hba.conf. We could also then check that the host name maps to the IP address.
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00569.php <nowiki>TODO Item: Allow pg_hba.conf to specify host names along with IP addresses</nowiki>]
}}

{{TodoItem
|Allow postgresql.conf file values to be changed via an SQL API, perhaps using SET GLOBAL}}

{{TodoItem
|Allow the server to be stopped/restarted via an SQL API}}

{{TodoItem
|Consider normalizing fractions in postgresql.conf, perhaps using '%'
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00550.php <nowiki>Fractions in GUC variables</nowiki>]
}}

{{TodoItem
|Allow Kerberos to disable stripping of realms so we can check the username@realm against multiple realms
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00009.php <nowiki>krb_match_realm patch</nowiki>]
}}

{{TodoItem
|Add functions to check correctness of configuration files before they are loaded "live"}}

{{TodoItem
|Improve LDAP authentication configuration options
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01745.php <nowiki>Proposed Patch - LDAPS support for servers on port 636 w/o TLS</nowiki>]
}}

{{TodoItem
|Add external tool to auto-tune some postgresql.conf parameters
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00000.php <nowiki>Re: Overhauling GUCS</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2008-11/msg00033.php
}}

{{TodoItem
|Add 'hostgss' pg_hba.conf option to allow GSS link-level encryption
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg01454.php <nowiki>Re: Plans for 8.4</nowiki>]
}}

{{TodoItem
|Process pg_hba.conf keywords as case-insensitive
* http://archives.postgresql.org/pgsql-hackers/2009-09/msg00432.php
}}

{{TodoEndSubsection}}

=== Tablespaces ===
{{TodoSubsection}}

{{TodoItem
|Allow a database in tablespace t1 with tables created in tablespace t2 to be used as a template for a new database created with default tablespace t2
|Currently all objects in the default database tablespace must have default tablespace specifications. This is because new databases are created by copying directories. If you mix default tablespace tables and tablespace-specified tables in the same directory, creating a new database from such a mixed directory would create a new database with tables that had incorrect explicit tablespaces. To fix this would require modifying pg_class in the newly copied database, which we don't currently do.}}

{{TodoItem
|Allow reporting of which objects are in which tablespaces
|This item is difficult because a tablespace can contain objects from multiple databases. There is a server-side function that returns the databases which use a specific tablespace, so this requires a tool that will call that function and connect to each database to find the objects in each database for that tablespace.}}

{{TodoItem
|Allow WAL replay of CREATE TABLESPACE to work when the directory structure on the recovery computer is different from the original}}

{{TodoItem
|Allow per-tablespace quotas}}

{{TodoItemDone
|Allow per-tablespace random_page_cost
* http://archives.postgresql.org/pgsql-hackers/2009-10/msg01128.php
* http://archives.postgresql.org/pgsql-hackers/2009-10/msg01486.php
}}

{{TodoEndSubsection}}

=== Statistics Collector ===
{{TodoSubsection}}

{{TodoItem
|Allow statistics last vacuum/analyze execution times to be displayed without requiring track_counts to be enabled
* [http://archives.postgresql.org/pgsql-docs/2007-04/msg00028.php <nowiki>row-level stats and last analyze time</nowiki>]
}}

{{TodoItem
|Clear table counters on TRUNCATE
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg00169.php <nowiki>Small TRUNCATE glitch</nowiki>]
}}

{{TodoItem
| Allow the clearing of cluster-level statistics
* http://archives.postgresql.org/pgsql-hackers/2009-03/msg00917.php
}}

{{TodoEndSubsection}}

=== Point-In-Time Recovery (PITR) ===
{{TodoSubsection}}

{{TodoItemDone
|Allow a warm standby system to also allow read-only statements
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00050.php <nowiki>Updated propsoal for read-only queries on PITR slaves (SoC 2007)</nowiki>]
}}

{{TodoItemEasy
|Create dump tool for write-ahead logs for use in determining transaction id for point-in-time recovery
|This is useful for checking PITR recovery.}}

{{TodoItem
|Allow recovery.conf to support the same syntax as postgresql.conf, including quoting
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00497.php <nowiki>recovery.conf parsing problems</nowiki>]
}}

{{TodoItem
|Allow archive_mode to be changed without server restart?
* http://archives.postgresql.org/pgsql-hackers/2008-10/msg01655.php
}}

{{TodoItem
|Consider avoiding WAL switching via archive_timeout if there has been no database activity
* http://archives.postgresql.org/pgsql-hackers/2010-01/msg01469.php
* http://archives.postgresql.org/pgsql-hackers/2010-02/msg00395.php
}}

{{TodoEndSubsection}}

=== SSL ===
{{TodoSubsection}}

{{TodoItem
|Allow SSL authentication/encryption over unix domain sockets
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00924.php <nowiki>Re: Spoofing as the postmaster</nowiki>]
}}

{{TodoItem
|Allow SSL key file permission checks to be optionally disabled when sharing SSL keys with other applications
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00069.php <nowiki>BUG #3809: SSL "unsafe" private key permissions bug</nowiki>]
}}

{{TodoItem
|Allow SSL CRL files to be re-read during configuration file reload, rather than requiring a server restart
|Unlike SSL CRT files, CRL (Certificate Revocation List) files are updated frequently
* http://archives.postgresql.org/pgsql-general/2008-12/msg00832.php
Alternatively or additionally supporting OCSP (online certificate security protocol) would provide real-time revocation discovery without reloading
}}

{{TodoItem
| Allow automatic selection of SSL client certificates from a certificate store
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00406.php <nowiki>Allow multiple certificates or keys in the postgresql.crt/.key files</nowiki>]
}}

{{TodoEndSubsection}}

== Data Types ==

{{TodoItem
|Change NUMERIC to enforce the maximum precision}}

{{TodoItem
|Reduce storage space for small NUMERICs
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg01331.php <nowiki>Saving space for common kinds of numeric values</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-02/msg00505.php <nowiki>Numeric patch to add special-case representations for < 8 bytes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00715.php <nowiki>Re: Reducing NUMERIC size for 8.3</nowiki>]
}}

{{TodoItem
|Fix data types where equality comparison isn't intuitive, e.g. box}}

{{TodoItem
|Add support for public SYNONYMs
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00519.php <nowiki>Proposal for SYNONYMS</nowiki>]
}}

{{TodoItem
|Add support for SQL-standard GENERATED/IDENTITY columns
* [http://archives.postgresql.org/pgsql-hackers/2006-07/msg00543.php <nowiki>Re: Three weeks left until feature freeze</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-08/msg00038.php <nowiki>GENERATED ... AS IDENTITY, Was: Re: Feature Freeze</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00344.php <nowiki>Behavior of GENERATED columns per SQL2003</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00076.php <nowiki>Re: [HACKERS] Behavior of GENERATED columns per SQL2003</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00604.php <nowiki>IDENTITY/GENERATED patch</nowiki>]
}}

{{TodoItem
|Consider placing all sequences in a single table, or create a system view
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]
}}

{{TodoItem
|Consider a special data type for regular expressions
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg01067.php <nowiki>Why is there a tsquery data type?</nowiki>]
}}

{{TodoItem
|Reduce BIT data type overhead using short varlena headers
* [http://archives.postgresql.org/pgsql-general/2007-12/msg00273.php <nowiki>storage size of "bit" data type..</nowiki>]
}}

{{TodoItem
|Allow adding/renaming/removing enumerated values to an existing enumerated data type
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01718.php <nowiki>Re: [COMMITTERS] pgsql: Update: < * Allow adding enumerated values to an existing</nowiki>]
}}

{{TodoItem
|Support scoped IPv6 addresses in inet type
* [http://archives.postgresql.org/pgsql-bugs/2007-05/msg00111.php <nowiki>strange problem with ip6</nowiki>]
}}

{{TodoItem
|Add JSON (JavaScript Object Notation) data type
|This would behave similar to the XML data type, which is stored as text, but allows element lookup and conversion functions.
* http://archives.postgresql.org/pgsql-hackers/2009-12/msg01494.php
* http://archives.postgresql.org/pgsql-hackers/2010-01/msg00001.php
}}

{{TodoItem
|Considering improving performance of computing CHAR() value lengths
* http://archives.postgresql.org/pgsql-hackers/2009-06/msg00900.php
* http://archives.postgresql.org/pgsql-hackers/2010-02/msg01787.php
}}

=== Domains ===
{{TodoSubsection}}

{{TodoItem
|Fix CREATE CAST on DOMAINs
* [http://archives.postgresql.org/pgsql-hackers/2006-05/msg00072.php <nowiki>bug? non working casts for domain</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-09/msg01681.php <nowiki>TODO: Fix CREATE CAST on DOMAINs</nowiki>]
}}

{{TodoItem
|Allow domains to be cast
* [http://archives.postgresql.org/pgsql-hackers/2003-06/msg01206.php <nowiki>Domain casting still doesn't work right</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00289.php <nowiki>domain casting?</nowiki>]
}}

{{TodoItem
|Make domains work better with polymorphic functions
* [http://archives.postgresql.org/message-id/4887.1228700773@sss.pgh.pa.us Polymorphic types vs. domains]
* [http://archives.postgresql.org/message-id/15535.1238774571@sss.pgh.pa.us some difficulties with fixing it]
}}

{{TodoEndSubsection}}

=== Dates and Times ===
{{TodoSubsection}}

{{TodoItem
|Allow infinite intervals just like infinite timestamps}}

{{TodoItem
|Allow TIMESTAMP WITH TIME ZONE to store the original timezone information, either zone name or offset from UTC
|If the TIMESTAMP value is stored with a time zone name, interval computations should adjust based on the time zone rules.
* [http://archives.postgresql.org/pgsql-hackers/2004-10/msg00705.php <nowiki>timestamp with time zone a la sql99</nowiki>]
}}

{{TodoItem
|Fix SELECT '0.01 years'::interval, '0.01 months'::interval}}

{{TodoItem
|Have timestamp subtraction not call justify_hours()?
* [http://archives.postgresql.org/pgsql-sql/2006-10/msg00059.php <nowiki>timestamp subtraction (was Re: formatting intervals with to_char)</nowiki>]
}}

{{TodoItem
|Improve timestamptz subtraction to be DST-aware
|Currently subtracting one date from another that crosses a daylight savings time adjustment can return '1 day 1 hour', but adding that back to the first date returns a time one hour in the future. This is caused by the adjustment of '25 hours' to '1 day 1 hour', and '1 day' is the same time the next day, even if daylight savings adjustments are involved.}}

{{TodoItem
|Fix interval display to support values exceeding 2^31 hours}}

{{TodoItem
|Add overflow checking to timestamp and interval arithmetic}}

{{TodoItemDone
|Revise the src/timezone/tznames abbreviation files:
* to add missing abbreviations
* to find abbreviations that can be safely promoted to the Default list
* {{messageLink|7867.1219793881@sss.pgh.pa.us|BUG #4377: casting result of timeofday() to timestamp fails in some timezones}}}}

{{TodoEndSubsection}}

=== Arrays ===
{{TodoSubsection}}

{{TodoItem
|Add support for arrays of domains
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00114.php <nowiki>Re: updated WIP: arrays of composites</nowiki>]
}}

{{TodoItem
|Allow single-byte header storage for array elements}}

{{TodoItem
|Add function to detect if an array is empty
* http://archives.postgresql.org/pgsql-hackers/2008-11/msg00475.php
}}

{{TodoItem
|Improve handling of empty arrays
* http://archives.postgresql.org/pgsql-hackers/2008-10/msg01033.php
}}

{{TodoItem
|Improve handling of NULLs in arrays
* http://archives.postgresql.org/pgsql-bugs/2008-11/msg00009.php
}}

{{TodoEndSubsection}}

=== Binary Data ===
{{TodoSubsection}}

{{TodoItem
|Improve vacuum of large objects, like contrib/vacuumlo?}}

{{TodoItemDone
|Add security checks for large objects}}

{{TodoItem
|Auto-delete large objects when referencing row is deleted
|contrib/lo offers this functionality.}}

{{TodoItem
|Allow read/write into TOAST values like large objects
|This requires the TOAST column to be stored EXTERNAL.}}

{{TodoItem
|Add API for 64-bit large object access
* [http://archives.postgresql.org/pgsql-hackers/2005-09/msg00781.php <nowiki>64-bit API for large objects</nowiki>]
}}

{{TodoEndSubsection}}

=== MONEY Data Type ===
{{TodoSubsection}}

{{TodoItem
|Add locale-aware MONEY type, and support multiple currencies
* [http://archives.postgresql.org/pgsql-general/2005-08/msg01432.php <nowiki>A real currency type</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01181.php <nowiki>Money type todos?</nowiki>]
}}

{{TodoItem
|MONEY dumps in a locale-specific format making it difficult to restore to a system with a different locale}}

{{TodoItem
|Allow MONEY to be easily cast to/from other numeric data types}}

{{TodoEndSubsection}}

=== Text Search ===
{{TodoSubsection}}

{{TodoItem
|Allow dictionaries to change the token that is passed on to later dictionaries
* [http://archives.postgresql.org/pgsql-patches/2007-11/msg00081.php <nowiki>a tsearch2 (8.2.4) dictionary that only filters out stopwords</nowiki>]
}}

{{TodoItem
|Consider a function-based API for '@@' searches
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00511.php <nowiki>Simplifying Text Search</nowiki>]
}}

{{TodoItem
|Improve text search error messages
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00966.php <nowiki>Poorly designed tsearch NOTICEs</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg01146.php <nowiki>Re: Poorly designed tsearch NOTICEs</nowiki>]
}}

{{TodoItem
|Consider changing error to warning for strings larger than one megabyte
* [http://archives.postgresql.org/pgsql-bugs/2008-02/msg00190.php <nowiki>BUG #3975: tsearch2 index should not bomb out of 1Mb limit</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-03/msg00062.php <nowiki>Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit</nowiki>]
}}

{{TodoItem
|tsearch and tsdicts regression tests fail in Turkish locale on glibc
* [http://archives.postgresql.org/message-id/49749645.5070801@gmx.net tsearch with Turkish locale]
}}

{{TodoEndSubsection}}

=== XML ===
{{TodoSubsection}}

{{TodoItem
|Allow xml arrays to be cast to other data types
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00981.php <nowiki>proposal casting from XML[] to int[], numeric[], text[]</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00231.php <nowiki>Re: proposal casting from XML[] to int[], numeric[], text[]</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00471.php <nowiki>Re: proposal casting from XML[] to int[], numeric[], text[]</nowiki>]
}}

{{TodoItem
|Add XML Schema validation and xmlvalidate function (SQL:2008)}}

{{TodoItem
|Add xmlvalidatedtd variant to support validating against a DTD?}}

{{TodoItem
|Relax-NG validation; libxml2 supports this already}}

{{TodoItem
|Make it work reliably for non-UTF8 server encoding (xpath()) in particular is known to not work)
* http://archives.postgresql.org/pgsql-bugs/2009-01/msg00135.php
* http://archives.postgresql.org/message-id/4110.1238973350@sss.pgh.pa.us}}

{{TodoItem
|Extra functions from SQL:2006: XMLDOCUMENT, XMLCAST, XMLTEXT}}

{{TodoItem
|Inline ORDER BY for XMLAGG. Example: "... XMLAGG(XMLELEMENT(...) ORDER BY col1) ..." (should be made to work with all aggregate functions)}}

{{TodoItem
|XMLNAMESPACES support in XMLELEMENT and elsewhere}}

{{TodoItem
|XSLT support; already available in contrib/xml2, but needs API fixes and adaptation to xml type.}}

{{TodoItem
|XML Canonical: Convert XML documents to canonical form to compare them. libxml2 has support for this.}}

{{TodoItem
|Pretty-printing XML: Parse a document and serialize it back in some indented form. libxml2 might support this.}}

{{TodoItem
|XMLQUERY (from SQL/XML standard)}}

{{TodoItem
|In some cases shredding could be better option (if there is no need in keeping XML docs entirely; if we have already developed tools that understand only relational data; etc) -- it would be a separate module that implements annotated schema decomposition technique, similar to DB2 and SQL Server functionality.}}

{{TodoItem
| Nested or repeated xpath() apparently mess up namespaces [http://archives.postgresql.org/pgsql-bugs/2008-03/msg00097.php] [http://archives.postgresql.org/pgsql-bugs/2008-03/msg00144.php] [http://archives.postgresql.org/pgsql-general/2008-03/msg00295.php] [http://archives.postgresql.org/pgsql-bugs/2008-07/msg00054.php] [http://archives.postgresql.org/message-id/004f01c90e91$138e9d10$3aabd730$@anstett@iaas.uni-stuttgart.de]}}

{{TodoItem
|XPath: Adding the <x> at the root causes problems [http://archives.postgresql.org/pgsql-bugs/2008-05/msg00184.php] [http://archives.postgresql.org/pgsql-bugs/2008-07/msg00054.php] [http://archives.postgresql.org/pgsql-general/2008-07/msg00613.php]}}

{{TodoItem
|xpath_table needs to be implemented/implementable to get rid of contrib/xml2 [http://archives.postgresql.org/pgsql-general/2008-05/msg00823.php]}}

{{TodoItem
|better handling of XPath data types [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00616.php] [http://archives.postgresql.org/message-id/004a01c90e90$4b986d90$e2c948b0$@anstett@iaas.uni-stuttgart.de]}}

{{TodoItem
|xpath_exists() is needed. It checks, whether or not the path specified exists in the XML value. (W/o this function we need to use weird "array_dims(xpath(...)) IS NOT NULL" syntax.)}}

{{TodoEndSubsection}}

== Functions ==

{{TodoItem
|Allow INET subnet tests using non-constants to be indexed}}

{{TodoItem
|Allow to_date() and to_timestamp() to accept localized month names}}

{{TodoItem
|Add missing parameter handling in to_char()
* [http://archives.postgresql.org/pgsql-hackers/2005-12/msg00948.php <nowiki>Re: to_char and i18n</nowiki>]
}}

{{TodoItem
|Throw an error from to_char() instead of printing a string of "#" when a number doesn't fit in the desired output format.
* discussed in [http://archives.postgresql.org/message-id/37ed240d0907290836w42187222n18664dfcbcb445b1@mail.gmail.com "to_char, support for EEEE format"]
}}

{{TodoItemDone
|Add functions to get/set bit values
* [http://archives.postgresql.org/pgsql-hackers/2004-01/msg00498.php <nowiki>implemented missing bitSetBit() and bitGetBit()</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2004-02/msg00478.php <nowiki>Re: implemented missing bitSetBit() and bitGetBit()</nowiki>]
}}

{{TodoItem
|Allow to_char() on interval values to accumulate the highest unit requested
|2= Some special format flag would be required to request such accumulation. Such functionality could also be added to EXTRACT. Prevent accumulation that crosses the month/day boundary because of the uneven number of days in a month.
* to_char(INTERVAL '1 hour 5 minutes', 'MI') => 65
* to_char(INTERVAL '43 hours 20 minutes', 'MI' ) => 2600
* to_char(INTERVAL '43 hours 20 minutes', 'WK:DD:HR:MI') => 0:1:19:20
* to_char(INTERVAL '3 years 5 months','MM') => 41}}

{{TodoItem
|Allow SQL-language functions to reference parameters by parameter name
|Currently SQL-language functions can only refer to dollar parameters, e.g. $1}}

{{TodoItem
|Add SPI_gettypmod() to return the typemod for a TupleDesc}}

{{TodoItem
|Enforce typmod for function inputs, function results and parameters for spi_prepare'd statements called from PLs
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg01403.php <nowiki>Re: BUG #2917: spi_prepare doesn't accept typename aliases</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2009-11/msg01160.php
}}

{{TodoItem
|Allow holdable cursors in SPI}}

{{TodoItem
|Tighten function permission checks
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00568.php <nowiki>Re: Security leak with trigger functions?</nowiki>]
}}

{{TodoItem
|Fix IS OF so it matches the ISO specification, and add documentation
* [http://archives.postgresql.org/pgsql-patches/2003-08/msg00060.php <nowiki>Re: [HACKERS] IS OF</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00060.php <nowiki>ToDo: add documentation for operator IS OF</nowiki>]
}}

{{TodoItem
|Add missing operators for geometric data types
|Some geometric types do not have the full suite of geometric operators, e.g. box @> point
* {{messageLink|4B0A8F0F.3020308@sigaev.ru|point_ops for GiST}}
}}

{{TodoItem
|Implement Boyer-Moore searching in LIKE queries
* {{messageLink|27645.1220635769@sss.pgh.pa.us|TODO item: Implement Boyer-Moore searching (First time hacker)}}
}}

{{TodoItem
|Prevent malicious functions from being executed with the permissions of unsuspecting users
|Index functions are safe, so VACUUM and ANALYZE are safe too. Triggers, CHECK and DEFAULT expressions, and rules are still vulnerable.
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00268.php <nowiki>Some notes about the index-functions security vulnerability</nowiki>]
}}

{{TodoItem
|Reduce memory usage of aggregates in set returning functions
* [http://archives.postgresql.org/pgsql-performance/2008-01/msg00031.php <nowiki>Re: Performance of aggregates over set-returning functions</nowiki>]
}}

{{TodoItem
|Fix /contrib/ltree operator
* [http://archives.postgresql.org/pgsql-bugs/2007-11/msg00044.php <nowiki>BUG #3720: wrong results at using ltree</nowiki>]
}}

{{TodoItem
|<nowiki>Fix inconsistent precedence of =, >, and < compared to <>, >=, and <=</nowiki>
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00145.php <nowiki>BUG #3822: Nonstandard precedence for comparison operators</nowiki>]
}}

{{TodoItem
|Fix regular expression bug when using complex back-references
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00000.php <nowiki>BUG #3645: regular expression back references seem broken</nowiki>]
}}

{{TodoItem
|Have /contrib/dblink reuse unnamed connections
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00895.php <nowiki>dblink un-named connection doesn't get re-used</nowiki>]
}}

{{TodoItem
|Allow calling of a procedure outside a SELECT that can control the transaction state
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01375.php <nowiki>Proposal: real procedures again (8.4)</nowiki>]
}}

{{TodoItemDone
|Add has_sequence_privilege()
* http://archives.postgresql.org/pgsql-hackers/2008-09/msg00032.php
}}

{{TodoItem
|Improve formatting of pg_get_viewdef() output
* http://archives.postgresql.org/pgsql-hackers/2009-01/msg01648.php
* http://archives.postgresql.org/pgsql-hackers/2009-08/msg01885.php
}}

{{TodoItem
|Add printf()-like functionality
* http://archives.postgresql.org/pgsql-hackers/2009-09/msg00367.php
}}

{{TodoItem
|Fix to_number() handling for values not matching the format string
* http://archives.postgresql.org/pgsql-hackers/2009-09/msg01447.php
}}

{{TodoItem
|Add function to dump pg_depend information cleanly
* http://archives.postgresql.org/pgsql-hackers/2009-09/msg00226.php
}}

== Multi-Language Support ==

{{TodoItem
|Add NCHAR (as distinguished from ordinary varchar),}}

{{TodoItem
|Allow more fine-grained collation selection; add CREATE COLLATION.
|Right now the collation is fixed at database creation time.
* [http://archives.postgresql.org/pgsql-hackers/2005-03/msg00932.php <nowiki>Re: Patch for collation using ICU</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2005-08/msg00039.php <nowiki>FW: Win32 unicode vs ICU</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2005-08/msg00309.php <nowiki>Re: FW: Win32 unicode vs ICU</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2005-09/msg00110.php <nowiki>Proof of concept COLLATE support with patch</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2005-09/msg00020.php <nowiki>For review: Initial support for COLLATE</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2005-12/msg01121.php <nowiki>Proposed COLLATE implementation</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-01/msg00767.php <nowiki>TODO item: locale per database patch (new iteration)</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2006-03/msg00233.php <nowiki>Re: FW: Win32 unicode vs ICU</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-09/msg00662.php <nowiki>Re: Fixed length data types issue</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2008-07/msg00557.php
* [[Todo:Collate]]
* [[Todo:ICU]]
* http://archives.postgresql.org/pgsql-hackers/2008-08/msg01362.php
* http://archives.postgresql.org/pgsql-hackers/2008-09/msg00012.php
* http://archives.postgresql.org/pgsql-hackers/2008-10/msg00868.php
* [http://www.unicode.org/unicode/reports/tr10/ Unicode collation algorithm]
}}

{{TodoItem
|Add a LOCALE option to CREATE DATABASE, as a shorthand
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00119.php <nowiki> Re: 8.4 open items list</nowiki>]
}}

{{TodoItem
|Support multiple simultaneous character sets, per SQL:2008}}

{{TodoItem
|Improve UTF8 combined character handling?}}

{{TodoItem
|Add octet_length_server() and octet_length_client()}}

{{TodoItem
|Make octet_length_client() the same as octet_length()?}}

{{TodoItem
|Fix problems with wrong runtime encoding conversion for NLS message files}}

{{TodoItem
|Add URL to more complete multi-byte regression tests
* [http://archives.postgresql.org/pgsql-hackers/2005-07/msg00272.php <nowiki>Multi-byte and client side character encoding tests for copy command..</nowiki>]
}}

{{TodoItem
|Fix contrib/fuzzystrmatch to work with multibyte encodings
* [http://archives.postgresql.org/pgsql-bugs/2009-04/msg00047.php <nowiki> soundex function returns UTF-16 characters</nowiki>]
}}

{{TodoItem
|Set client encoding based on the client operating system encoding
|Currently client_encoding is set in postgresql.conf, which defaults to the server encoding.
* [http://archives.postgresql.org/pgsql-hackers/2006-08/msg01696.php <nowiki>Re: [GENERAL] invalid byte sequence ?</nowiki>]
}}

{{TodoItem
|Change memory allocation for multi-byte functions so memory is allocated inside conversion functions
|Currently we preallocate memory based on worst-case usage.}}

{{TodoItem
|Add ability to use case-insensitive regular expressions on multi-byte characters
|ILIKE already works with multi-byte characters
* http://archives.postgresql.org/pgsql-hackers/2008-12/msg00433.php
* {{MessageLink|20091201210024.B1393753FB7@cvs.postgresql.org|A partial solution for UTF-8}}
}}

{{TodoItem
|Improve encoding of connection startup messages sent to the client
|Currently some authentication error messages are sent in the server encoding
* http://archives.postgresql.org/pgsql-general/2008-12/msg00801.php
* http://archives.postgresql.org/pgsql-general/2009-01/msg00005.php
}}

{{TodoItem
|Have pg_stat_activity display query strings in the correct client encoding
* http://archives.postgresql.org/pgsql-hackers/2009-01/msg00131.php
}}

{{TodoItem
|More sensible support for Unicode combining characters, normal forms
* http://archives.postgresql.org/message-id/200904141532.44618.peter_e@gmx.net
}}

== Views / Rules ==

{{TodoItem
|Automatically create rules on views so they are updateable, per SQL:2008
|We can only auto-create rules for simple views. For more complex cases users will still have to write rules manually.
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00586.php <nowiki>Proposal for updatable views</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2006-08/msg00255.php <nowiki>Updatable views</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2009-01/msg01746.php
* http://wiki.postgresql.org/wiki/Updatable_views
}}

{{TodoItem
|Add the functionality for WITH CHECK OPTION clause of CREATE VIEW}}

{{TodoItem
|Allow VIEW/RULE recompilation when the underlying tables change
|This is both difficult and controversial.
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01723.php Re: About "Allow VIEW/RULE recompilation when the underlying tables change"]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01724.php Re: About "Allow VIEW/RULE recompilation when the underlying tables change"]
}}

{{TodoItem
|Make it possible to use RETURNING together with conditional DO INSTEAD rules, such as for partitioning setups
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00577.php <nowiki>RETURNING and DO INSTEAD ... Intentional or not?</nowiki>]
}}

{{TodoItem
|Add the ability to automatically create materialized views
|Right now materialized views require the user to create triggers on the main table to keep the summary table current. SQL syntax should be able to manager the triggers and summary table automatically. A more sophisticated implementation would automatically retrieve from the summary table when the main table is referenced, if possible.}}

{{TodoItem
|Improve ability to modify views via ALTER TABLE
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00691.php <nowiki>Re: idea: storing view source in system catalogs</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg01410.php <nowiki>modifying views</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg00300.php <nowiki>Re: patch: Add columns via CREATE OR REPLACE VIEW</nowiki>]
}}

{{TodoItem
|Prevent low-cost functions from seeing unauthorized view rows
* http://archives.postgresql.org/pgsql-hackers/2009-10/msg01346.php
}}

== SQL Commands ==

{{TodoItem
|Add CORRESPONDING BY to UNION/INTERSECT/EXCEPT}}

{{TodoItem
|Add ROLLUP, CUBE, GROUPING SETS options to GROUP BY
* http://archives.postgresql.org/pgsql-hackers/2008-10/msg00838.php
* http://archives.postgresql.org/pgsql-hackers/2009-05/msg00466.php
}}

{{TodoItemEasy
|Allow SET CONSTRAINTS to be qualified by schema/table name}}

{{TodoItemEasy
|Fix TRUNCATE ... RESTART IDENTITY so its effect on sequences is rolled back on transaction abort
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00550.php <nowiki>Re: [PATCHES] TRUNCATE TABLE with IDENTITY</nowiki>]
}}

{{TodoItem
|Allow PREPARE of cursors}}

{{TodoItem
|Allow finer control over the caching of prepared query plans
|Currently anonymous (un-named) queries prepared via the libpq API are replanned every time bind parameters are supplied --- allow SQL PREPARE to do the same. Also, allow control over replanning prepared queries either manually or automatically when statistics for execute parameters differ dramatically from those used during planning.
* http://archives.postgresql.org/message-id/201002151911.o1FJBYh22763@momjian.us
}}

{{TodoItem
|Improve logging of prepared transactions recovered during startup
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg00092.php <nowiki>"recovering prepared transaction" after server restart message</nowiki>]
}}

{{TodoItem
|Allow prepared transactions with temporary tables created and dropped in the same transaction, and when an ON COMMIT DELETE ROWS temporary table is accessed
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00047.php <nowiki>Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables</nowiki>]
* [http://archives.postgresql.org/message-id/492543D5.9050904@enterprisedb.com A suggestion on how to implement this]
}}

{{TodoItem
|Add a GUC variable to warn about non-standard SQL usage in queries}}

{{TodoItem
|Add SQL-standard MERGE/REPLACE/UPSERT command
|MERGE is typically used to merge two tables. REPLACE or UPSERT command does UPDATE, or on failure, INSERT. This is similar to UPDATE, then for unmatched rows, INSERT. Whether concurrent access allows modifications which could cause row loss is implementation independent. To implement this cleanly requires that the table have a unique index so duplicate checking can be easily performed. It is possible to do it without a unique index if we require the user to LOCK the table before the MERGE.
* [http://archives.postgresql.org/pgsql-hackers/2005-11/msg00501.php <nowiki>someone working to add merge?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2005-11/msg00536.php <nowiki>MERGE vs REPLACE</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01157.php <nowiki>MERGE SQL Statement</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01475.php <nowiki>MERGE Specification</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01890.php <nowiki>Internal design of MERGE, with Rules</nowiki>]
}}

{{TodoItem
|Add NOVICE output level for helpful messages like automatic sequence/index creation}}

{{TodoItem
|Add GUC to issue notice about statements that use unjoined tables}}

{{TodoItem
|Allow EXPLAIN to identify tables that were skipped because of constraint_exclusion}}

{{TodoItemDone
|Allow EXPLAIN output to be more easily processed by scripts, perhaps XML
* http://archives.postgresql.org/pgsql-hackers/2009-05/msg00857.php
}}

{{TodoItem
|Enable standard_conforming_strings by default in 8.6?
|When this is done, backslash-quote should be prohibited in non-E<nowiki>''</nowiki> strings because of possible confusion over how such strings treat backslashes. Basically, <nowiki>''</nowiki> is always safe for a literal single quote, while \' might or might not be based on the backslash handling rules.}}

{{TodoItem
|Simplify dropping roles that have objects in several databases}}

{{TodoItem
|Allow the count returned by SELECT, etc to be represented as an int64 to allow a higher range of values}}

{{TodoItem
|Add support for WITH RECURSIVE ... CYCLE
* http://archives.postgresql.org/pgsql-hackers/2008-10/msg00291.php}}

{{TodoItem
|Add DEFAULT .. AS OWNER so permission checks are done as the table owner
|This would be useful for SERIAL nextval() calls and CHECK constraints.}}

{{TodoItem
|Allow DISTINCT to work in multiple-argument aggregate calls}}

{{TodoItem
|Add column to pg_stat_activity that shows the progress of long-running commands like CREATE INDEX and VACUUM
* [http://archives.postgresql.org/pgsql-patches/2008-04/msg00203.php <nowiki>EXPLAIN progress info</nowiki>]
}}

{{TodoItem
|Allow INSERT/UPDATE/DELETE ... RETURNING inside a SELECT 'FROM' clause or target list
|Actually it would be saner to allow this in WITH
* [http://archives.postgresql.org/pgsql-general/2006-09/msg00803.php <nowiki>8.2: select from an INSERT returning?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg00693.php <nowiki>Re: SQL functions, INSERT/UPDATE/DELETE RETURNING, and triggers</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00124.php <nowiki>cannot use result of (insert..returning)</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00979.php <nowiki>insert ... delete ... returning ... ?</nowiki>]
* [http://archives.postgresql.org/pgsql-general/2009-06/msg00357.php Using results from DELETE ... RETURNING]
}}

{{TodoItem
|Allow INSERT/UPDATE/DELETE ... RETURNING in common table expressions
* http://archives.postgresql.org/pgsql-hackers/2009-10/msg00472.php
}}

{{TodoItem
|Add comments on system tables/columns using the information in catalogs.sgml
|Ideally the information would be pulled from the SGML file automatically.}}

{{TodoItem
|Prevent the specification of conflicting transaction read/write options
* http://archives.postgresql.org/pgsql-hackers/2009-01/msg00684.php
}}

{{TodoItem
|Support LATERAL subqueries
|Lateral subqueries can reference columns of tables defined outside the subquery at the same level, i.e. ''laterally''.
For example, a LATERAL subquery in a FROM clause could reference tables defined in the same FROM clause.
Currently only the columns of tables defined ''above'' subqueries are recognized.
* http://archives.postgresql.org/pgsql-hackers/2009-09/msg00292.php
* http://archives.postgresql.org/pgsql-hackers/2009-10/msg00991.php
}}

{{TodoItemDone
|Forbid COMMENT on columns of an index
|Postgres currently allows comments to be placed on the columns of an index, but pg_dump doesn't handle them and the column names themselves are implementation-dependent.
* http://archives.postgresql.org/message-id/27676.1237906577@sss.pgh.pa.us
}}

{{TodoItem
|Add support for functional dependencies
|This would allow omitting GROUP BY columns when grouping by the primary key.
}}

=== CREATE ===
{{TodoSubsection}}

{{TodoItem
|Allow CREATE TABLE AS to determine column lengths for complex expressions like SELECT col1 || col2}}

{{TodoItem
|Have WITH CONSTRAINTS also create constraint indexes
* [http://archives.postgresql.org/pgsql-patches/2007-04/msg00149.php <nowiki>Re: CREATE TABLE LIKE INCLUDING INDEXES support</nowiki>]
}}

{{TodoItem
|Move NOT NULL constraint information to pg_constraint
|Currently NOT NULL constraints are stored in pg_attribute without any designation of their origins, e.g. primary keys. One manifest problem is that dropping a PRIMARY KEY constraint does not remove the NOT NULL constraint designation. Another issue is that we should probably force NOT NULL to be propagated from parent tables to children, just as CHECK constraints are. (But then does dropping PRIMARY KEY affect children?)
* http://archives.postgresql.org/message-id/19768.1238680878@sss.pgh.pa.us
* http://archives.postgresql.org/message-id/200909181005.n8IA5Ris061239@wwwmaster.postgresql.org
}}

{{TodoItem
|Prevent concurrent CREATE TABLE from sometimes returning a cryptic error message
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00169.php <nowiki>BUG #3692: Conflicting create table statements throw unexpected error</nowiki>]
}}

{{TodoItem
|Add CREATE SCHEMA ... LIKE that copies a schema}}

{{TodoItemDone
|Add CREATE TABLE LIKE ... INCLUDING COMMENTS}}

{{TodoItemDone
|Have CREATE TABLE LIKE copy column storage parameters
* http://archives.postgresql.org/pgsql-hackers/2008-07/msg01417.php
* http://archives.postgresql.org/pgsql-hackers/2008-08/msg00423.php
* http://archives.postgresql.org/pgsql-hackers/2008-09/msg00576.php
* http://archives.postgresql.org/pgsql-hackers/2008-09/msg00824.php
}}

{{TodoItem
|CREATE OR REPLACE FUNCTION might leave dependent objects depending on the function in inconsistent state
* [http://archives.postgresql.org/pgsql-general/2008-08/msg00985.php indexes on functions and create or replace function]
}}

{{TodoItem
|Allow GLOBAL temporary tables to exist as empty by default in all sessions
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00006.php <nowiki>what is difference between LOCAL and GLOBAL TEMP TABLES in PostgreSQL</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2009-04/msg01329.php
* http://archives.postgresql.org//pgsql-hackers/2009-05/msg00016.php
}}

{{TodoItem
|Add OR REPLACE to CREATE LANGUAGE
* http://archives.postgresql.org/pgsql-patches/2008-05/msg00057.php
}}

{{TodoItem
|Allow the creation of "distinct" types
* http://archives.postgresql.org/pgsql-hackers/2008-10/msg01647.php
}}

{{TodoEndSubsection}}

=== UPDATE ===
{{TodoSubsection}}

{{TodoItem
|<nowiki>Allow UPDATE tab SET ROW (col, ...) = (SELECT...)</nowiki>
* [http://archives.postgresql.org/pgsql-hackers/2006-07/msg01308.php <nowiki>Re: [PATCHES] extension for sql update</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00865.php <nowiki>UPDATE using sub selects</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-04/msg00315.php <nowiki>UPDATE using sub selects</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-03/msg00237.php <nowiki>Re: UPDATE using sub selects</nowiki>]
}}

{{TodoItem
|Research self-referential UPDATEs that see inconsistent row versions in read-committed mode
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00507.php <nowiki>Concurrently updating an updatable view</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00016.php <nowiki>Re: Do we need a TODO? (was Re: Concurrently updating anupdatable view)</nowiki>]
}}

{{TodoItem
|Improve performance of EvalPlanQual mechanism that rechecks already-updated rows
|This is related to the previous item, which questions whether it even has the right semantics
* [http://archives.postgresql.org/pgsql-bugs/2008-09/msg00045.php <nowiki>BUG #4401: concurrent updates to a table blocks one update indefinitely</nowiki>]
* [http://archives.postgresql.org/pgsql-bugs/2009-07/msg00302.php <nowiki>BUG #4945: Parallel update(s) gone wild</nowiki>]
}}

{{TodoEndSubsection}}

=== ALTER ===
{{TodoSubsection}}

{{TodoItem
|Have ALTER TABLE RENAME rename SERIAL sequence names
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]
}}

{{TodoItemEasy
|Allow ALTER TABLE ... ALTER CONSTRAINT ... RENAME
* [http://archives.postgresql.org/pgsql-patches/2006-02/msg00168.php <nowiki>ALTER CONSTRAINT RENAME patch reverted</nowiki>]
}}

{{TodoItem
|Add ALTER TABLE RENAME CONSTRAINT}}

{{TodoItem
|Have ALTER SEQUENCE RENAME rename the sequence name stored in the sequence table
* [http://archives.postgresql.org/pgsql-bugs/2007-09/msg00092.php <nowiki>BUG #3619: Renaming sequence does not update its 'sequence_name' field</nowiki>]
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00007.php <nowiki>Re: BUG #3619: Renaming sequence does not update its 'sequence_name' field</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]
}}

{{TodoItem
|Add ALTER DOMAIN to modify the underlying data type}}

{{TodoItemEasy
|Allow ALTER TABLE to change constraint deferrability and actions}}

{{TodoItem
|Add missing object types for ALTER ... SET SCHEMA}}

{{TodoItem
|Allow ALTER TABLESPACE to move to different directories}}

{{TodoItem
|Allow moving system tables to other tablespaces, where possible
|Currently non-global system tables must be in the default database tablespace. Global system tables can never be moved.}}

{{TodoItem
|Have ALTER INDEX update the name of a constraint using that index}}

{{TodoItem
|Allow column display reordering by recording a display, storage, and permanent id for every column?
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00782.php <nowiki>Re: column ordering, was Re: [PATCHES] Enums patch v2</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2008-11/msg01029.php
}}

{{TodoItem
|Allow an existing index to be marked as a table's primary key
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg00500.php <nowiki>Setting a pre-existing index as a primary key</nowiki>]
}}

{{TodoItem
|Allow ALTER TYPE on composite types to perform operations similar to ALTER TABLE
* http://archives.postgresql.org/pgsql-hackers/2008-12/msg00245.php
}}

{{TodoItem
|Don't require table rewrite on ALTER TABLE ... ALTER COLUMN TYPE, when the old and new data types are binary compatible
* http://archives.postgresql.org/message-id/200903040137.n241bAUV035002@wwwmaster.postgresql.org
* http://archives.postgresql.org/pgsql-patches/2006-10/msg00154.php
}}

{{TodoEndSubsection}}

=== CLUSTER ===
{{TodoSubsection}}

{{TodoItem
|Automatically maintain clustering on a table
|This might require some background daemon to maintain clustering during periods of low usage. It might also require tables to be only partially filled for easier reorganization. Another idea would be to create a merged heap/index data file so an index lookup would automatically access the heap data too. A third idea would be to store heap rows in hashed groups, perhaps using a user-supplied hash function.
* [http://archives.postgresql.org/pgsql-performance/2004-08/msg00350.php <nowiki>Equivalent praxis to CLUSTERED INDEX?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00155.php <nowiki>Re: Grouped Index Tuples</nowiki>]
* http://community.enterprisedb.com/git/
* http://archives.postgresql.org/pgsql-performance/2009-10/msg00346.php
}}

{{TodoItemEasy
|Add default clustering to system tables
|To do this, determine the ideal cluster index for each system table and set the cluster setting during initdb.}}

{{TodoItem
|Improve CLUSTER performance by sorting to reduce random I/O
* http://archives.postgresql.org/pgsql-hackers/2008-08/msg01371.php
}}

{{TodoItemEasy
|Make CLUSTER VERBOSE more verbose.
|It is also used by new VACUUM FULL VERBOSE.}}

{{TodoEndSubsection}}

=== COPY ===
{{TodoSubsection}}

{{TodoItem
|Allow COPY to report error lines and continue
|This requires the use of a savepoint before each COPY line is processed, with ROLLBACK on COPY failure.
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00572.php <nowiki>Re: VLDB Features</nowiki>]
}}

{{TodoItem
|Allow COPY on a newly-created table to skip WAL logging
|On crash recovery, the table involved in the COPY would be removed or have its heap and index files truncated. One issue is that no other backend should be able to add to the table at the same time, which is something that is currently allowed. This currently is done if the table is created inside the same transaction block as the COPY because no other backends can see the table.}}

{{TodoItem
|Allow COPY FROM to create index entries in bulk
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00811.php <nowiki>Batch update of indexes on data loading</nowiki>]
}}

{{TodoItem
|Allow COPY in CSV mode to control whether a quoted zero-length string is treated as NULL
|Currently this is always treated as a zero-length string, which generates an error when loading into an integer column
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00905.php <nowiki>Re: [PATCHES] allow CSV quote in NULL</nowiki>]
}}

{{TodoItem
|Improve COPY performance
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00954.php <nowiki>Re: 8.3 / 8.2.6 restore comparison</nowiki>]
}}

{{TodoItem
|Allow COPY to report errors sooner
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01169.php <nowiki>Timely reporting of COPY errors</nowiki>]
}}

{{TodoItemDone
|Improve bytea COPY format
* http://archives.postgresql.org/pgsql-hackers/2009-05/msg00192.php
}}

{{TodoItem
|Allow COPY to handle other number formats eg. the German notation. Best would be something like WITH DECIMAL ','.
}}

{{TodoEndSubsection}}

=== GRANT/REVOKE ===
{{TodoSubsection}}

{{TodoItemDone
|Allow GRANT/REVOKE permissions to be applied to all schema objects with one command
|The proposed syntax is: GRANT SELECT ON ALL TABLES IN public TO phpuser; GRANT SELECT ON NEW TABLES IN public TO phpuser;
* http://archives.postgresql.org/pgsql-hackers/2009-06/msg01014.php
}}

{{TodoItemDone
|Allow GRANT/REVOKE permissions to be inherited by objects based on schema permissions
* http://wiki.postgresql.org/wiki/DefaultACL
}}

{{TodoItem
|Allow SERIAL sequences to inherit permissions from the base table?}}

{{TodoItem
|Allow dropping of a role that has connection rights
* http://archives.postgresql.org/pgsql-hackers/2008-05/msg00736.php
}}
{{TodoEndSubsection}}

=== DECLARE CURSOR ===
{{TodoSubsection}}

{{TodoItem
|Prevent DROP TABLE from dropping a table referenced by its own open cursor?}}

{{TodoItem
|Provide some guarantees about the behavior of cursors that invoke volatile functions
* [http://archives.postgresql.org/message-id/20997.1244563664@sss.pgh.pa.us Re: Cursor with hold emits the same row more than once across commits in 8.3.7]
}}

{{TodoEndSubsection}}

=== INSERT ===
{{TodoSubsection}}

{{TodoItem
|Allow INSERT/UPDATE of the system-generated oid value for a row}}

{{TodoItem
|In rules, allow VALUES() to contain a mixture of 'old' and 'new' references}}

{{TodoEndSubsection}}

=== SHOW/SET ===
{{TodoSubsection}}

{{TodoItem
|Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM ANALYZE, and CLUSTER}}

{{TodoItem
|Rationalize the discrepancy between settings that use values in bytes and SHOW that returns the object count
* http://archives.postgresql.org/pgsql-docs/2008-07/msg00007.php
}}

{{TodoEndSubsection}}

=== LISTEN/NOTIFY ===
{{TodoSubsection}}

{{TodoItemDone
|Allow LISTEN/NOTIFY to store info in memory rather than tables
|Currently LISTEN/NOTIFY information is stored in pg_listener. Storing such information in memory would improve performance.}}

{{TodoItemDone
|Add optional textual message to NOTIFY
|This would allow an informational message to be added to the notify message, perhaps indicating the row modified or other custom information.}}

{{TodoItem
|Allow NOTIFY in rules involving conditionals}}

{{TodoEndSubsection}}

=== Window Functions ===
See {{messageLink|357.1230492361@sss.pgh.pa.us|TODO items for window functions}}.
{{TodoSubsection}}
{{TodoItem
|Support creation of user-defined window functions.
|We have the ability to create new window functions written in C. Is it
worth the effort to create an API that would let them be written in PL/pgsql, etc?}}

{{TodoItem
|Implement full support for window framing clauses.
|The cases we support now are basically those where no row ever exits the frame as the current row advances. To do better requires some rethinking of the window aggregate support.}}

{{TodoItem
|Look at tuplestore performance issues.
|The tuplestore_in_memory() thing is just a band-aid, we ought to try to solve it properly. tuplestore_advance seems like a weak spot as well.
* http://archives.postgresql.org/pgsql-hackers/2008-12/msg00152.php
}}

{{TodoItem|Do we really need so much duplicated code between Agg and WindowAgg?}}

{{TodoItem
|Teach planner to evaluate multiple windows in the optimal order.
|Currently windows are always evaluated in the query-specified order.
* http://archives.postgresql.org/message-id/3CDAD71E9D70417290FCF66F0178D1E1@amd64
}}

{{TodoEndSubsection}}

== Integrity Constraints ==
=== Keys ===

{{TodoSubsection}}

{{TodoItemDone
|Allow DEFERRABLE UNIQUE constraints
|<nowiki>This would allow UPDATE tab SET col = col + 1 to work if col has a unique index. Currently, uniqueness checks are done while the command is being executed, rather than at the end of the statement or transaction.</nowiki>
* http://people.planetpostgresql.org/greg/index.php?/archives/46-Updating-unique-columns.html
* [http://archives.postgresql.org/pgsql-hackers/2006-09/msg01458.php <nowiki>Re: Unique index: update error</nowiki>]
}}

{{TodoItem
|Improve deferrable unique constraints for cases with many conflicts
|The current implementation fires a trigger for each potentially conflicting row. This might not scale well for an update that changes many key values at once.
}}

{{TodoEndSubsection}}

=== Referential Integrity ===
{{TodoSubsection}}

{{TodoItem
|Add MATCH PARTIAL referential integrity}}

{{TodoItem
|Change foreign key constraint for array -> element to mean element in array?}}

{{TodoItem
|Fix problem when cascading referential triggers make changes on cascaded tables, seeing the tables in an intermediate state
* [http://archives.postgresql.org/pgsql-hackers/2005-09/msg00174.php <nowiki>Re: [PATCHES] Work-in-progress referential action trigger timing</nowiki>]
}}

{{TodoItem
|Optimize referential integrity checks
* [http://archives.postgresql.org/pgsql-performance/2005-10/msg00458.php <nowiki>Re: Effects of cascading references in foreign keys</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00744.php <nowiki>Can't ri_KeysEqual() consider two nulls as equal?</nowiki>]
}}

{{TodoEndSubsection}}

== Server-Side Languages ==

{{TodoItem
|Add support for polymorphic arguments and return types to languages other than PL/PgSQL}}

{{TodoItem
|Add capability to create and call PROCEDURES}}

{{TodoItem
|Add support for OUT and INOUT parameters to languages other than PL/PgSQL}}

{{TodoItem
|Add more fine-grained specification of functions taking arbitrary data types
* http://archives.postgresql.org/pgsql-hackers/2009-09/msg00367.php
}}

=== PL/pgSQL ===
{{TodoSubsection}}

{{TodoItemDone
|Allow function parameters to be passed by name, get_employee_salary(12345 AS emp_id, 2001 AS tax_year)
* http://archives.postgresql.org/pgsql-hackers/2008-08/msg00559.php
* http://archives.postgresql.org/pgsql-hackers/2008-12/msg00880.php
}}

{{TodoItem
|Allow handling of %TYPE arrays, e.g. tab.col%TYPE[]}}

{{TodoItem
|<nowiki>Allow listing of record column names, and access to record columns via variables, e.g. columns := r.(*), tval2 := r.(colname)</nowiki>
* [http://archives.postgresql.org/pgsql-patches/2005-07/msg00458.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2006-05/msg00302.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00031.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]
}}

{{TodoItem
|Add support for SCROLL cursors}}

{{TodoItem
|Add support for WITH HOLD cursors}}

{{TodoItem
|Allow row and record variables to be set to NULL constants, and allow NULL tests on such variables
|Because a row is not scalar, do not allow assignment from NULL-valued scalars.
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg00070.php <nowiki>NULL and plpgsql rows</nowiki>]
}}

{{TodoItemDone
|Review handling of MOVE and FETCH
* [http://archives.postgresql.org/pgsql-patches/2007-04/msg00527.php <nowiki>Re: actualised forgotten Magnus's patch for plpgsql MOVE statement</nowiki>]
}}

{{TodoItemDone
|Improve logic of determining if an identifier is a variable or a column name
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00436.php <nowiki>Re: plpgsql and qualified variable names</nowiki>]
* * http://archives.postgresql.org/message-id/603c8f070903061741l1f11ba59q783745cc3cb79dba@mail.gmail.com
}}

{{TodoItem
|Consider keeping separate cached copies when search_path changes
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg01009.php <nowiki>pl/pgsql Plan Invalidation and search_path</nowiki>]
}}

{{TodoItemDone
|Improve PL/pgSQL's ability to cope with rowtypes containing dropped columns
* [http://archives.postgresql.org/pgsql-bugs/2008-09/msg00004.php <nowiki>Bug in RETURN QUERY</nowiki>]
}}

{{TodoItem
|Improve handling of NULL row values vs. NULL rows
* http://archives.postgresql.org/pgsql-hackers/2008-09/msg01758.php
}}

{{TodoEndSubsection}}

=== PL/Perl ===
{{TodoSubsection}}

{{TodoItem
|Allow data to be passed in native language formats, rather than only text
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00289.php <nowiki>plperl vs. bytea</nowiki>]
}}

{{TodoItem
|Allow regex operations in plperl using UTF8 characters in non-UTF8 encoded databases.}}

{{TodoEndSubsection}}

=== PL/Python ===
{{TodoSubsection}}

{{TodoItem
|Add table function support}}

{{TodoItem
|Add tracebacks
* [http://archives.postgresql.org/pgsql-patches/2006-02/msg00288.php <nowiki>Re: plpython tracebacks</nowiki>]
}}

{{TodoItemDone
|Add support for Python 3
* [http://archives.postgresql.org/message-id/3544.1238817272@sss.pgh.pa.us <nowiki>Re: Python 3.0 does not work with PL/Python</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2009-07/msg01519.php
}}

{{TodoItem
|Develop a trusted variant of PL/Python.}}

{{TodoItem
|Allow arrays as function arguments and return values.}}

{{TodoItem
|Create a new restricted execution class that will allow passing function arguments in as locals. Passing them as globals means functions cannot be called recursively.}}

{{TodoItem
|Functions cache the input and output functions for their arguments, so the following will make PostgreSQL unhappy:

create table users (first_name text, last_name text);
create function user_name(user) returns text as 'mycode' language plpython;
select user_name(user) from users;
alter table add column user_id integer;
select user_name(user) from users;

You have to drop and create the function(s) each time its arguments
are modified (not nice), or don't cache the input and output functions
(slower?), or check if the structure of the argument has been
altered (is this possible, easy, quick?) and recreate cache.}}

{{TodoItem
|Better documentation}}

{{TodoItem
|Add a DB-API compliant interface on top of the SPI interface.}}

{{TodoItem
|check encoding validity of values passed back to Postgres in function returns, trigger tuple changes, or SPI calls.}}

{{TodoEndSubsection}}

=== PL/Tcl ===
{{TodoSubsection}}

{{TodoItem
|Add table function support}}

{{TodoItem
|check encoding validity of values passed back to Postgres in function returns, trigger tuple changes, or SPI calls.}}

{{TodoEndSubsection}}

== Clients ==

{{TodoItem
|Add a function like pg_get_indexdef() that report more detailed index information
* [http://archives.postgresql.org/pgsql-bugs/2007-12/msg00166.php <nowiki>BUG #3829: Wrong index reporting from pgAdmin III (v1.8.0 rev 6766-6767)</nowiki>]
}}

=== pg_ctl ===
{{TodoSubsection}}

{{TodoItem
|Allow pg_ctl to work properly with configuration files located outside the PGDATA directory
|pg_ctl can not read the pid file because it isn't located in the config directory but in the PGDATA directory. The solution is to allow pg_ctl to read and understand postgresql.conf to find the data_directory value.
* http://archives.postgresql.org/pgsql-bugs/2009-10/msg00024.php
}}

{{TodoItem
|Have the postmaster write a random number to a file on startup that pg_ctl checks against the contents of a pg_ping response on its initial connection (without login)
|This will protect against connecting to an old instance of the postmaster in a different or deleted subdirectory.
* http://archives.postgresql.org/pgsql-bugs/2009-10/msg00110.php
* http://archives.postgresql.org/pgsql-bugs/2009-10/msg00156.php
}}

{{TodoItem
|Modify pg_ctl behavior and exit codes to make it easier to write an LSB conforming init script
|It may be desirable to condition some of the changes on a command-line switch, to avoid breaking existing scripts. A Linux shell (sh) script is referenced which has been tested and seems to provide a high degree of conformance in multiple environments. Study of this script might suggest areas where pg_ctl could be modified to make writing an LSB conforming script easier; however, some aspects of that script would be unnecessary with other suggested changes to pg_ctl, and discussion on the lists did not reach consensus on support for all aspects of this script. Further discussion of particular changes is needed before beginning any work.
* [[Lsb_conforming_init_script|LSB conforming init script]]
These threads should be studied for other ideas on improvements:
* http://archives.postgresql.org/pgsql-hackers/2009-08/msg01390.php
* http://archives.postgresql.org/pgsql-hackers/2009-08/msg01843.php
* http://archives.postgresql.org/pgsql-hackers/2009-09/msg00008.php

}}

{{TodoEndSubsection}}

=== psql ===
{{TodoSubsection}}

{{TodoItem
|Have psql \ds show all sequences and their settings
* http://archives.postgresql.org/pgsql-hackers/2008-07/msg00916.php
* http://archives.postgresql.org/pgsql-hackers/2008-12/msg00401.php
}}

{{TodoItem
|Have \d on a sequence indicate if the sequences is owned by a table}}

{{TodoItem
|Move psql backslash database information into the backend, use mnemonic commands?
|This would allow non-psql clients to pull the same information out of the database as psql.
* [http://archives.postgresql.org/pgsql-hackers/2004-01/msg00191.php <nowiki>Re: psql \d option list overloaded</nowiki>]
}}

{{TodoItem
|Make psql's \d commands more consistent in its handling of schemas
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00014.php <nowiki>Re: psql and schemas</nowiki>]
}}

{{TodoItem
|Consistently display privilege information for all objects in psql}}

{{TodoItem
|Add auto-expanded mode so expanded output is used if the row length is wider than the screen width.
|Consider using auto-expanded mode for backslash commands like \df+.}}

{{TodoItem
|Prevent tab completion of SET TRANSACTION from querying the database and therefore preventing the transaction isolation level from being set.
|Currently SET <tab> causes a database lookup to check all supported session variables. This query causes problems because setting the transaction isolation level must be the first statement of a transaction.}}

{{TodoItem
|Add a \set variable to control whether \s displays line numbers
|Another option is to add \# which lists line numbers, and allows command execution.
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php <nowiki>Re: psql possible TODO</nowiki>]
}}

{{TodoItem
|Prevent escape string warnings when object names have backslashes
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00227.php <nowiki>Psql command-line completion bug</nowiki>]
}}

{{TodoItem
|Have \d show child tables that inherit from the specified parent}}

{{TodoItem
|Include the symbolic SQLSTATE name in verbose error reports
* [http://archives.postgresql.org/pgsql-general/2007-09/msg00438.php <nowiki>Re: Checking is TSearch2 query is valid</nowiki>]
}}

{{TodoItem
|Add prompt escape to display the client and server versions
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00310.php <nowiki>WIP patch for TODO Item: Add prompt escape to display the client and server versions</nowiki>]
}}

{{TodoItem
|Add option to wrap column values at whitespace boundaries, rather than chopping them at a fixed width.
|Currently, "wrapped" format chops values into fixed widths. Perhaps the word wrapping could use the same algorithm documented in the W3C specification.
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00404.php <nowiki>Re: psql wrapped format default for backslash-d commands</nowiki>]
* http://www.w3.org/TR/CSS21/tables.html#auto-table-layout}}

{{TodoItem
|Add "auto" expanded mode that outputs in expanded format if "wrapped" mode can't wrap the output to the screen width
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00417.php <nowiki>Re: psql wrapped format default for backslash-d commands</nowiki>]
}}

{{TodoItem
|Support the ReST table output format
|Details about the ReST format: http://docutils.sourceforge.net/rst.html#reference-documentation
* http://archives.postgresql.org/pgsql-hackers/2008-08/msg01007.php
* http://archives.postgresql.org/pgsql-hackers/2009-01/msg00518.php
* http://archives.postgresql.org/pgsql-hackers/2009-01/msg00609.php
}}

{{TodoItem
|Add option to print advice for people familiar with other databases
* http://archives.postgresql.org/pgsql-hackers/2010-01/msg01845.php
}}

{{TodoItem
|Consider showing TOAST and index sizes in \dt+
* http://archives.postgresql.org/pgsql-general/2010-01/msg00912.php
}}

{{TodoItem
|Allow \dd to show constraint comments
* http://archives.postgresql.org/pgsql-hackers/2009-09/msg00436.php
* http://archives.postgresql.org/pgsql-general/2009-09/msg00199.php
}}

{{TodoItem
|Add ability to edit views with \ev
* http://archives.postgresql.org/pgsql-hackers/2009-09/msg00023.php
}}

{{TodoEndSubsection}}

=== pg_dump / pg_restore ===
{{TodoSubsection}}

{{TodoItemDone
|Add dumping of comments on composite type columns
* {{MessageLink|20090723225940.E35D975331E@cvs.postgresql.org|Teach pg_dump to dump comments attached to the columns of a composite type.}}
}}

{{TodoItemEasy
|<nowiki>Add full object name to the tag field. eg. for operators we need '=(integer, integer)', instead of just '='.</nowiki>}}

{{TodoItemEasyDone
| Add comments to output indicating version of pg_dump and of the database server
}}

{{TodoItem
|Add pg_dumpall custom format dumps?}}

{{TodoItem
|Avoid using platform-dependent locale names in pg_dumpall output
|Using native locale names puts roadblocks in the way of porting a dump to another platform. One possible solution is to get
CREATE DATABASE to accept some agreed-on set of locale names and fix them up to meet the platform's requirements.
* http://archives.postgresql.org/message-id/21396.1241716688@sss.pgh.pa.us
}}

{{TodoItem
|Allow selection of individual object(s) of all types, not just tables}}

{{TodoItem
|In a selective dump, allow dumping of an object and all its dependencies}}

{{TodoItem
|Add options like pg_restore -l and -L to pg_dump}}

{{TodoItem
|Add support for multiple pg_restore -t options, like pg_dump
|pg_restore's -t switch is less useful than pg_dump's in quite a few ways: no multiple switches, no pattern matching, no ability to pick up indexes and other dependent items for a selected table. It should be made to handle this switch just like pg_dump does.}}

{{TodoItem
|Stop dumping CASCADE on DROP TYPE commands in clean mode}}

{{TodoItem
|Allow pg_dump --clean to drop roles that own objects or have privileges
|tgl says: if this is about pg_dumpall, it's done as of 8.4. If it's really about pg_dump, what does it mean? pg_dump has no business dropping roles.}}

{{TodoItem
|Change pg_dump so that a comment on the dumped database is applied to the loaded database, even if the database has a different name. This will require new backend syntax, perhaps COMMENT ON CURRENT DATABASE.}}

{{TodoItem
|Remove unnecessary function pointer abstractions in pg_dump source code}}

{{TodoItem
|Allow pg_dump to utilize multiple CPUs and I/O channels by dumping multiple objects simultaneously
|The difficulty with this is getting multiple dump processes to produce a single dump output file. It also would require several sessions to share the same snapshot.
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00205.php <nowiki>pg_dump additional options for performance</nowiki>]
}}

{{TodoItem
|Allow pg_restore to load different parts of the COPY data for a single table simultaneously}}

{{TodoItem
|Remove support for dumping from pre-7.3 servers
|In 7.3 and later, we can get accurate dependency information from the server. pg_dump still contains a lot of crufty code
to try to deal with the lack of dependency info in older servers, but the usefulness of maintaining that code grows small.}}

{{TodoItem
|Allow pre/data/post files when schema and data are dumped separately, for performance reasons
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00205.php <nowiki>pg_dump additional options for performance</nowiki>]
* http://archives.postgresql.org/pgsql-patches/2008-07/msg00185.php
}}

{{TodoItem
|Have pg_dump -C emit ALTER DATABASE ... SET commands after database creation
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg01031.php <nowiki>ALTER DATABASE vs pg_dump</nowiki>]
}}

{{TodoItem
|Allow parallel restore of tar dumps
* http://archives.postgresql.org/pgsql-hackers/2009-02/msg01154.php
}}

{{TodoEndSubsection}}

=== ecpg ===
{{TodoSubsection}}

{{TodoItem
|Docs
|Document differences between ecpg and the SQL standard and information about the Informix-compatibility module.}}

{{TodoItem
|Solve cardinality > 1 for input descriptors / variables?}}

{{TodoItem
|Add a semantic check level, e.g. check if a table really exists}}

{{TodoItem
|fix handling of DB attributes that are arrays}}

{{TodoItemDone
|Implement SQLDA
|{{MessageLink|20100105163823.7C70B753FB7@cvs.postgresql.org|add sqlda support to ecpg in both native and compatibility mode}}
}}

{{TodoItem
|Fix nested C comments}}

{{TodoItemEasy
|sqlwarn[6] should be 'W' if the PRECISION or SCALE value specified}}

{{TodoItem
|Make SET CONNECTION thread-aware, non-standard?}}

{{TodoItem
|Allow multidimensional arrays}}

{{TodoItem
|Implement COPY FROM STDIN}}

{{TodoItem
|Provide a way to specify size of a bytea parameter
* [http://archives.postgresql.org/message-id/200906192131.n5JLVoMo044178@wwwmaster.postgresql.org <nowiki>BUG #4866: ECPG and BYTEA</nowiki>]
}}

{{TodoEndSubsection}}

=== libpq ===
{{TodoSubsection}}

{{TodoItem
|Add PQescapeIdentifierConn()}}

{{TodoItem
|Prevent PQfnumber() from lowercasing unquoted column names
|PQfnumber() should never have been doing lowercasing, but historically it has so we need a way to prevent it}}

{{TodoItem
|Allow statement results to be automatically batched to the client
|Currently all statement results are transferred to the libpq client before libpq makes the results available to the application. This feature would allow the application to make use of the first result rows while the rest are transferred, or held on the server waiting for them to be requested by libpq. One complexity is that a statement like SELECT 1/col could error out mid-way through the result set.}}

{{TodoItem
|Consider disallowing multiple queries in PQexec() as an additional barrier to SQL injection attacks
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg00184.php <nowiki>Re: InitPostgres and flatfiles question</nowiki>]
}}

{{TodoItem
|Add PQexecf() that allows complex parameter substitution
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01803.php <nowiki>Last minute mini-proposal (I know, know) for PQexecf()</nowiki>]
}}

{{TodoItem
|Add SQLSTATE and severity to errors generated within libpq itself
* [http://archives.postgresql.org/pgsql-interfaces/2007-11/msg00015.php <nowiki>v8.1: Error severity on libpq PGconn*</nowiki>]
}}

{{TodoItem
|Add code to detect client encoding and locale from the operating system environment
* http://archives.postgresql.org/pgsql-hackers/2009-06/msg01040.php
}}

{{TodoItem
|Add keepalive support to libpq
* http://archives.postgresql.org/pgsql-hackers/2010-02/msg00611.php
}}

{{TodoItem
|Add support for interface/ipaddress binding to libpq
* http://archives.postgresql.org/pgsql-hackers/2010-02/msg01811.php
}}

{{TodoEndSubsection}}

== Triggers ==

{{TodoItem
|Improve storage of deferred trigger queue
|Right now all deferred trigger information is stored in backend memory. This could exhaust memory for very large trigger queues. This item involves dumping large queues into files, or doing some kind of join to process all the triggers, some bulk operation, or a bitmap.
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00876.php <nowiki>Re: BUG #4204: COPY to table with FK has memory leak</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2009-10/msg00464.php
}}

{{TodoItem
|Allow triggers to be disabled in only the current session.
|This is currently possible by starting a multi-statement transaction, modifying the system tables, performing the desired SQL, restoring the system tables, and committing the transaction. ALTER TABLE ... TRIGGER requires a table lock so it is not ideal for this usage.}}

{{TodoItem
|With disabled triggers, allow pg_dump to use ALTER TABLE ADD FOREIGN KEY
|If the dump is known to be valid, allow foreign keys to be added without revalidating the data.}}

{{TodoItem
|Allow statement-level triggers to access modified rows}}

{{TodoItem
|When statement-level triggers are defined on a parent table, have them fire only on the parent table, and fire child table triggers only where appropriate
* http://archives.postgresql.org/pgsql-hackers/2008-11/msg01883.php
}}

{{TodoItemDone
|Support triggers on columns
* [http://archives.postgresql.org/pgsql-patches/2005-07/msg00107.php <nowiki>Column-level triggers</nowiki>]
}}

{{TodoItem
|Allow AFTER triggers on system tables
|System tables are modified in many places in the backend without going through the executor and therefore not causing triggers to fire. To complete this item, the functions that modify system tables will have to fire triggers.}}

{{TodoItem
|Tighten trigger permission checks
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00564.php <nowiki>Security leak with trigger functions?</nowiki>]
}}

{{TodoItem
|Allow BEFORE INSERT triggers on views
* [http://archives.postgresql.org/pgsql-general/2007-02/msg01466.php <nowiki>Re: Why can't I put a BEFORE EACH ROW trigger on a view?</nowiki>]
}}

{{TodoItem
|Add database and transaction-level triggers
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00451.php <nowiki>Proposal for db level triggers</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00620.php <nowiki>triggers on prepare, commit, rollback... ?</nowiki>]
}}

{{TodoItem
|Reduce locking requirements for creating a trigger
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00635.php <nowiki>Re: Change lock requirements for adding a trigger</nowiki>]
}}

== Inheritance ==

{{TodoItem
|Allow inherited tables to inherit indexes, UNIQUE constraints, and primary/foreign keys}}

{{TodoItem
|Honor UNIQUE INDEX on base column in INSERTs/UPDATEs on inherited table, e.g. INSERT INTO inherit_table (unique_index_col) VALUES (dup) should fail
|The main difficulty with this item is the problem of creating an index that can span multiple tables.}}

{{TodoItem
|Determine whether ALTER TABLE / SET SCHEMA should work on inheritance hierarchies (and thus support ONLY). If yes, implement it.}}

{{TodoItem
|ALTER TABLE variants sometimes support recursion and sometimes not, but this is poorly/not documented, and the ONLY marker would then be silently ignored. Clarify the documentation, and reject ONLY if it is not supported.}}

== Indexes ==

{{TodoItem
|Add UNIQUE capability to non-btree indexes}}

{{TodoItem
|Prevent index uniqueness checks when UPDATE does not modify the column
|Uniqueness (index) checks are done when updating a column even if the column is not modified by the UPDATE.
However, HOT already short-circuits this in common cases, so more work might not be helpful.}}

{{TodoItem
|Allow the creation of on-disk bitmap indexes which can be quickly combined with other bitmap indexes
|Such indexes could be more compact if there are only a few distinct values. Such indexes can also be compressed. Keeping such indexes updated can be costly.
* [http://archives.postgresql.org/pgsql-patches/2005-07/msg00512.php <nowiki>Re: Bitmap index AM</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg01107.php <nowiki>Bitmap index thoughts</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00265.php <nowiki>Stream bitmaps</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01214.php <nowiki>Re: Bitmapscan changes - Requesting further feedback</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00013.php <nowiki>Updated bitmap index patch</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00741.php <nowiki>Reviewing new index types (was Re: [PATCHES] Updated bitmap indexpatch)</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2008-10/msg01023.php
}}

{{TodoItem
|Allow accurate statistics to be collected on indexes with more than one column or expression indexes, perhaps using per-index statistics
* [http://archives.postgresql.org/pgsql-performance/2006-10/msg00222.php <nowiki>Re: Simple join optimized badly?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01131.php <nowiki>Stats for multi-column indexes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00741.php <nowiki>Cross-column statistics revisited</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg01431.php <nowiki>Multi-Dimensional Histograms</nowiki>]
}}

{{TodoItem
|Consider having a larger statistics target for indexed columns and expression indexes.
}}

{{TodoItem
|Consider smaller indexes that record a range of values per heap page, rather than having one index entry for every heap row
|This is useful if the heap is clustered by the indexed values.
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00341.php <nowiki>Grouped Index Tuples</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg01264.php <nowiki>Grouped Index Tuples</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00465.php <nowiki>Grouped Index Tuples / Clustered Indexes</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-03/msg00163.php <nowiki>Bitmapscan changes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00014.php <nowiki>Re: GIT patch</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00487.php <nowiki>Re: Index Tuple Compression Approach?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01589.php <nowiki>Re: Index AM change proposals, redux</nowiki>]
}}

{{TodoItem
|Add REINDEX CONCURRENTLY, like CREATE INDEX CONCURRENTLY
|This is difficult because you must upgrade to an exclusive table lock to replace the existing index file. CREATE INDEX CONCURRENTLY does not have this complication. This would allow index compaction without downtime.
* [http://archives.postgresql.org/pgsql-performance/2007-08/msg00289.php <nowiki>Re: When/if to Reindex</nowiki>]
}}

{{TodoItem
|Allow multiple indexes to be created concurrently, ideally via a single heap scan
|pg_restore allows parallel index builds, but it is done via subprocesses, and there is no SQL interface for this.
}}

{{TodoItem
|Consider sorting entries before inserting into btree index
* [http://archives.postgresql.org/pgsql-general/2008-01/msg01010.php <nowiki>Re: ATTN: Clodaldo was Performance problem. Could it be related to 8.3-beta4?</nowiki>]
}}

{{TodoItem
|Allow index scans to return matching index keys, not just the matching heap locations
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01657.php <nowiki>Re: Is this TODO item done?</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2009-08/msg01477.php
}}

{{TodoItem
|Allow creation of an index that can do comparisons to test if a value is between two column values
* http://archives.postgresql.org/pgsql-hackers/2008-05/msg00757.php
}}

{{TodoItem
|Consider using "effective_io_concurrency" for index scans
* Currently only bitmap scans use this, which might be fine because most multi-row index scans use bitmap scans.
}}

=== GIST ===
{{TodoSubsection}}

{{TodoItem
|Add more GIST index support for geometric data types}}

{{TodoItem
|Allow GIST indexes to create certain complex index types, like digital trees (see Aoki)}}

{{TodoItem
|Fix performance issues in contrib/seg and contrib/cube GiST support
* [http://archives.postgresql.org/message-id/alpine.DEB.2.00.0904161633160.4053@aragorn.flymine.org GiST index performance]
* [http://archives.postgresql.org/message-id/alpine.DEB.2.00.0904221704470.22330@aragorn.flymine.org draft patch]
}}

{{TodoEndSubsection}}

=== GIN ===
{{TodoSubsection}}

{{TodoItem
|Support empty indexed values (such as zero-element arrays) properly
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00237.php contrib/intarray vs empty arrays]
* [http://archives.postgresql.org/pgsql-bugs/2009-05/msg00118.php BUG #4806: Bug with GiST index and empty integer array]
}}

{{TodoItem
|Behave correctly for cases where some elements of an indexed value are NULL}}

{{TodoItem
|Support queries that require a full scan
* [http://archives.postgresql.org/pgsql-general/2009-05/msg00402.php Issue report]
* [http://archives.postgresql.org/pgsql-general/2007-06/msg01132.php Older issue report]
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg01581.php Original discussion of issue and proposed resolution]
}}

{{TodoEndSubsection}}

=== Hash ===
{{TodoSubsection}}

{{TodoItemDone
|Pack hash index buckets onto disk pages more efficiently
|Currently only one hash bucket can be stored on a page. Ideally several hash buckets could be stored on a single page and greater granularity used for the hash algorithm.
* [http://archives.postgresql.org/pgsql-hackers/2004-06/msg00168.php <nowiki>Why hash indexes suck</nowiki>]
However, the binary searching within a hash page probably renders this issue moot.
* [http://archives.postgresql.org/pgsql-committers/2008-09/msg00154.php <nowiki>pgsql: Change hash indexes to store only the hash code rather than the</nowiki>]
}}

{{TodoItem
|Add hash WAL logging for crash recovery}}

{{TodoItem
|Allow multi-column hash indexes}}

{{TodoEndSubsection}}

== Catalogs ==

{{TodoItemDone
|Improve performance of information_schema views
* [http://archives.postgresql.org/message-id/29921.1230246746%40sss.pgh.pa.us table_privileges is way too slow]
}}

{{TodoItemDone
|Improve information_schema's entries for precision and scale
* http://archives.postgresql.org/pgsql-hackers/2009-05/msg01485.php
}}

== Sorting ==

{{TodoItem
|Consider whether duplicate keys should be sorted by block/offset
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00558.php <nowiki>Remove hacks for old bad qsort() implementations?</nowiki>]
}}

{{TodoItem
|Consider being smarter about memory and external files used during sorts
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg01101.php <nowiki>Sorting Improvements for 8.4</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00045.php <nowiki>Re: Sorting Improvements for 8.4</nowiki>]
}}

{{TodoItem
|Consider detoasting keys before sorting}}

== Fsync ==

{{TodoItem
|Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options
|Ideally this requires a separate test program that can be run at initdb time or optionally later. Consider O_SYNC when O_DIRECT exists.}}

{{TodoItem
|Add program to test if fsync has a delay compared to non-fsync}}

{{TodoItem
|Consider sorting writes during checkpoint
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00541.php <nowiki>Sorted writes in checkpoint</nowiki>]
* http://archives.postgresql.org/pgsql-patches/2008-07/msg00050.php
}}

== Cache Usage ==

{{TodoItem
|Speed up COUNT(*)
|We could use a fixed row count and a +/- count to follow MVCC visibility rules, or a single cached value could be used and invalidated if anyone modifies the table. Another idea is to get a count directly from a unique index, but for this to be faster than a sequential scan it must avoid access to the heap to obtain tuple visibility information.}}

{{TodoItem
|Provide a way to calculate an "estimated COUNT(*)"
|Perhaps by using the optimizer's cardinality estimates or random sampling.
* [http://archives.postgresql.org/pgsql-hackers/2005-11/msg00943.php <nowiki>Re: Improving count(*)</nowiki>]
}}

{{TodoItem
|Allow data to be pulled directly from indexes
|Currently indexes do not have enough tuple visibility information to allow data to be pulled from the index without also accessing the heap. One way to allow this is to set a bit on index tuples to indicate if a tuple is currently visible to all transactions when the first valid heap lookup happens. This bit would have to be cleared when a heap tuple is expired.
Another idea is to maintain a bitmap of heap pages where all rows are visible to all backends, and allow index lookups to reference that bitmap to avoid heap lookups, perhaps the same bitmap we might add someday to determine which heap pages need vacuuming. Frequently accessed bitmaps would have to be stored in shared memory. One 8k page of bitmaps could track 512MB of heap pages.
A third idea would be for a heap scan to check if all rows are visible and if so set a per-table flag which can be checked by index scans. Any change to the table would have to clear the flag. To detect changes during the heap scan a counter could be set at the start and checked at the end --- if it is the same, the table has not been modified --- any table change would increment the counter.
* [http://archives.postgresql.org/pgsql-patches/2007-10/msg00166.php <nowiki>Re: [HACKERS] Including Snapshot Info with Indexes</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-01/msg00049.php <nowiki>Re: [HACKERS] Including Snapshot Info with Indexes</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg01094.php <nowiki>TODO item: Allow data to be pulled directly from indexes</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2008-09/msg00003.php
}}

{{TodoItem
|Consider automatic caching of statements at various levels:
* Parsed query tree
* Query execute plan
* Query results

:
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg00823.php <nowiki>Cached Query Plans (was: global prepared statements)</nowiki>]
}}

{{TodoItem
|Consider increasing internal areas (NUM_CLOG_BUFFERS) when shared buffers is increased
* [http://archives.postgresql.org/pgsql-hackers/2005-10/msg01419.php <nowiki>Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",)</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00030.php <nowiki>clog_buffers to 64 in 8.3?</nowiki>]
* [http://archives.postgresql.org/pgsql-performance/2007-08/msg00024.php <nowiki>CLOG Patch</nowiki>]
}}

{{TodoItem
|Consider decreasing the amount of memory used by PrivateRefCount
|
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg00797.php <nowiki>PrivateRefCount (for 8.3)</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg00752.php <nowiki>Re: PrivateRefCount (for 8.3)</nowiki>]
}}

{{TodoItem
|Consider allowing higher priority queries to have referenced buffer cache pages stay in memory longer
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00562.php <nowiki>Re: How to keep a table in memory?</nowiki>]
}}

== Vacuum ==

{{TodoItemDone
|Improve VACUUM FULL's speed when major data movement is needed
|For large table adjustments during VACUUM FULL, it would be faster to cluster or reindex rather than update the indexes piecemeal as it does now. Also, this behavior tends to bloat the indexes.
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00024.php <nowiki>Revitalising VACUUM FULL for 8.3</nowiki>]
* [http://archives.postgresql.org/pgsql-performance/2007-05/msg00296.php <nowiki>Re: [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00307.php <nowiki>Re: Unexpected VACUUM FULL failure</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00656.php A note about VACUUM syntax]
* http://archives.postgresql.org/pgsql-hackers/2009-09/msg01045.php
}}

{{TodoItem
|Clean up VACUUM FULL's klugy transaction management
|VACUUM FULL marks its transaction committed before it's really done, which means a PANIC if it fails after that point. This needs to be
split into two transactions.
}}

{{TodoItem
|Auto-fill the free space map by scanning the buffer cache or by checking pages written by the background writer
* [http://archives.postgresql.org/pgsql-hackers/2006-02/msg01125.php <nowiki>Dead Space Map</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00011.php <nowiki>Re: Automatic free space map filling</nowiki>]
}}

{{TodoItem
|Improve tracking of total relation tuple counts now that vacuum doesn't always scan the whole heap
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00531.php Partial vacuum versus pg_class.reltuples]
}}

{{TodoItem
|Bias FSM towards returning free space near the beginning of the heap file, in hopes that empty pages at the end can be truncated by VACUUM}}

{{TodoItem
|Make FSM return free space based on table clustering, to assist in maintaining clustering?}}

{{TodoItem
|Consider a more compact data representation for dead tuple locations within VACUUM
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00143.php <nowiki>Re: Have vacuum emit a warning when it runs out of maintenance_work_mem</nowiki>]
}}

{{TodoItem
|Provide more information in order to improve user-side estimates of dead space bloat in relations
* [http://archives.postgresql.org/pgsql-general/2009-05/msg01039.php <nowiki>Re: Bloated Table</nowiki>]
}}

=== Auto-vacuum ===
{{TodoSubsection}}

{{TodoItemEasy
|Issue log message to suggest VACUUM FULL if a table is nearly empty?}}

{{TodoItem
|Prevent long-lived temporary tables from causing frozen-xid advancement starvation
|The problem is that autovacuum cannot vacuum them to set frozen xids; only the session that created them can do that.
* [http://archives.postgresql.org/pgsql-general/2007-06/msg01645.php <nowiki>Re: AutoVacuum Behaviour Question</nowiki>]
}}

{{TodoItem
|Prevent autovacuum from running if an old transaction is still running from the last vacuum
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00899.php <nowiki>Re: Autovacuum and OldestXmin</nowiki>]
}}

{{TodoItem
|Have free space allocation bias away from using trailing table pages
|This improves the chances of truncating the table during vacuum
* http://archives.postgresql.org/pgsql-hackers/2009-09/msg01124.php
}}

{{TodoEndSubsection}}

== Locking ==

{{TodoItem
|Fix priority ordering of read and write light-weight locks
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00893.php <nowiki>lwlocks and starvation</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2004-11/msg00905.php <nowiki>Re: lwlocks and starvation</nowiki>]
}}

{{TodoItem
|Fix problem when multiple subtransactions of the same outer transaction hold different types of locks, and one subtransaction aborts
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg01011.php <nowiki>FOR SHARE vs FOR UPDATE locks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00001.php <nowiki>Re: FOR SHARE vs FOR UPDATE locks</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00435.php <nowiki>Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00773.php <nowiki>Re: savepoints and upgrading locks</nowiki>]
}}

{{TodoItem
|Allow UPDATEs on only non-referential integrity columns not to conflict with referential integrity locks
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00073.php <nowiki>Referential Integrity and SHARE locks</nowiki>]
}}

{{TodoItem
|Add idle_in_transaction_timeout GUC so locks are not held for long periods of time}}

{{TodoItem
|Improve deadlock detection when a page cleaning lock conflicts with a shared buffer that is pinned
* [http://archives.postgresql.org/pgsql-bugs/2008-01/msg00138.php <nowiki>BUG #3883: Autovacuum deadlock with truncate?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php <nowiki>Thoughts about bug #3883</nowiki>]
* [http://archives.postgresql.org/pgsql-committers/2008-01/msg00365.php <nowiki>Re: pgsql: Add checks to TRUNCATE, CLUSTER, and REINDEX to prevent</nowiki>]
}}

{{TodoItem
|Detect deadlocks involving LockBufferForCleanup()
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php <nowiki>Thoughts about bug #3883</nowiki>]
}}

{{TodoItem
|Consider a lock timeout parameter
* http://archives.postgresql.org/pgsql-hackers/2009-05/msg00485.php
}}

{{TodoItem
|Consider improving serialized transaction behavior to avoid anomalies
* http://archives.postgresql.org/pgsql-hackers/2009-05/msg00217.php
* http://archives.postgresql.org/pgsql-hackers/2009-05/msg01136.php
* http://archives.postgresql.org/pgsql-hackers/2009-06/msg00035.php
}}

== Startup Time Improvements ==

{{TodoItem
|Experiment with multi-threaded backend for backend creation
|This would prevent the overhead associated with process creation. Most operating systems have trivial process creation time compared to database startup overhead, but a few operating systems (Win32, Solaris) might benefit from threading. Also explore the idea of a single session using multiple threads to execute a statement faster.}}

== Write-Ahead Log ==

{{TodoItem
|Eliminate need to write full pages to WAL before page modification
|Currently, to protect against partial disk page writes, we write full page images to WAL before they are modified so we can correct any partial page writes during recovery. These pages can also be eliminated from point-in-time archive files.
* [http://archives.postgresql.org/pgsql-hackers/2002-06/msg00655.php <nowiki>Re: Index Scans become Seq Scans after VACUUM ANALYSE</nowiki>]
}}

{{TodoItem
|When full page writes are off, write CRC to WAL and check file system blocks on recovery
|If CRC check fails during recovery, remember the page in case a later CRC for that page properly matches.}}

{{TodoItem
|Write full pages during file system write and not when the page is modified in the buffer cache
|This allows most full page writes to happen in the background writer. It might cause problems for applying WAL on recovery into a partially-written page, but later the full page will be replaced from WAL.}}

{{TodoItemDone
|Allow WAL traffic to be streamed to another server for stand-by replication}}

{{TodoItem
|Reduce WAL traffic so only modified values are written rather than entire rows
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01589.php <nowiki>Reduction in WAL for UPDATEs</nowiki>]
}}

{{TodoItem
|Allow WAL information to recover corrupted pg_controldata
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00025.php <nowiki>Re: [HACKERS] pg_resetxlog -r flag</nowiki>]
}}

{{TodoItem
|Find a way to reduce rotational delay when repeatedly writing last WAL page
|Currently fsync of WAL requires the disk platter to perform a full rotation to fsync again. One idea is to write the WAL to different offsets that might reduce the rotational delay.
* [http://archives.postgresql.org/pgsql-hackers/2002-11/msg00483.php <nowiki>500 tpsQL + WAL log implementation</nowiki>]
}}

{{TodoItem
|Allow WAL logging to be turned off for a table, but the table might be dropped or truncated during crash recovery
|Allow tables to bypass WAL writes and just fsync() dirty pages on commit. This should be implemented using ALTER TABLE, e.g. <nowiki>ALTER TABLE PERSISTENCE [ DROP | TRUNCATE | DEFAULT ]</nowiki>. Tables using non-default logging should not use referential integrity with default-logging tables. A table without dirty buffers during a crash could perhaps avoid the drop/truncate.
* [http://archives.postgresql.org/pgsql-hackers/2005-12/msg01016.php <nowiki>Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and</nowiki>]
}}

{{TodoItem
|Allow WAL logging to be turned off for a table, but the table would avoid being truncated/dropped
|To do this, only a single writer can modify the table, and writes must happen only on new pages so the new pages can be removed during crash recovery. Readers can continue accessing the table. Such tables probably cannot have indexes. One complexity is the handling of indexes on TOAST tables.
* [http://archives.postgresql.org/pgsql-hackers/2005-12/msg01016.php <nowiki>Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and</nowiki>]
}}

{{TodoItem
|Speed WAL recovery by allowing more than one page to be prefetched
|This should be done utilizing the same infrastructure used for prefetching in general to avoid introducing complex error-prone code in WAL replay.
* [http://archives.postgresql.org/pgsql-general/2007-12/msg00683.php <nowiki>Slow PITR restore</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00497.php <nowiki>Re: [GENERAL] Slow PITR restore</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg01279.php <nowiki>Read-ahead and parallelism in redo recovery</nowiki>]
}}

{{TodoItem
|Improve WAL concurrency by increasing lock granularity
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00556.php <nowiki>Reworking WAL locking</nowiki>]
}}

{{TodoItem
|Be more aggressive about creating WAL files
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01325.php <nowiki>Re: PANIC caused by open_sync on Linux</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2004-07/msg01075.php <nowiki>PreallocXlogFiles</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2005-04/msg00556.php <nowiki>WAL/PITR additional items</nowiki>]
}}

{{TodoItem
|Have resource managers report the duration of their status changes
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01468.php <nowiki>Recovery of Multi-stage WAL actions</nowiki>]
}}

{{TodoItem
|Move pgfoundry's xlogdump to /contrib and have it rely more closely on the WAL backend code
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00035.php <nowiki>xlogdump</nowiki>]
}}

{{TodoItem
|Close deleted WAL files held open in *nix by long-lived read-only backends
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg01754.php <nowiki>Deleted WAL files held open by backends in Linux</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00060.php <nowiki>Re: Deleted WAL files held open by backends in Linux</nowiki>]
}}

== Optimizer / Executor ==

{{TodoItem
|Improve selectivity functions for geometric operators}}

{{TodoItem
|Precompile SQL functions to avoid overhead}}

{{TodoItem
|Create utility to compute accurate random_page_cost value}}

{{TodoItem
|Consider increasing the default values of from_collapse_limit, join_collapse_limit, and/or geqo_threshold
* [http://archives.postgresql.org/message-id/4136ffa0905210551u22eeb31bn5655dbe7c9a3aed5@mail.gmail.com from_collapse_limit vs. geqo_threshold]
}}

{{TodoItem
|Improve ability to display optimizer analysis using OPTIMIZER_DEBUG}}

{{TodoItem
|Have EXPLAIN ANALYZE issue NOTICE messages when the estimated and actual row counts differ by a specified percentage}}

{{TodoItem
|Log statements where the optimizer row estimates were dramatically different from the number of rows actually found?}}

{{TodoItem
|Improve how ANALYZE computes in-doubt tuples
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00771.php <nowiki>VACUUM/ANALYZE counting of in-doubt tuples</nowiki>]
}}

{{TodoItem
|Consider compressed annealing to search for query plans
|This might replace GEQO.
* http://archives.postgresql.org/message-id/15658.1241278636%40sss.pgh.pa.us
}}

{{TodoItem
|Consider using a hash for joining to a large IN (VALUES ...) list
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00450.php <nowiki>Planning large IN lists</nowiki>]
}}

{{TodoItem
|Allow single batch hash joins to preserve outer pathkeys
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00806.php Re: Potential Join Performance Issue]
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoItem
|"lazy" hash tables - look up only the tuples that are actually requested
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoItem
|Avoid building the same hash table more than once during the same query
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoItem
|Avoid hashing for distinct and then re-hashing for hash join
* [http://archives.postgresql.org/message-id/4136ffa0902191346g62081081v8607f0b92c206f0a@mail.gmail.com Re: Fixing Grittner's planner issues]
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]
}}

{{TodoItem
|Allow hashing to be used on arrays, if the element type is hashable
* http://archives.postgresql.org/message-id/11087.1244905821@sss.pgh.pa.us
}}

{{TodoItem
|Improve use of expression indexes for ORDER BY
* http://archives.postgresql.org/pgsql-hackers/2009-08/msg01553.php
}}

== Background Writer ==

{{TodoItem
|Consider having the background writer update the transaction status hint bits before writing out the page
|Implementing this requires the background writer to have access to system catalogs and the transaction status log.}}

{{TodoItem
|Consider adding buffers the background writer finds reusable to the free list
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php <nowiki>Background LRU Writer/free list</nowiki>]
}}

{{TodoItem
|Automatically tune bgwriter_delay based on activity rather then using a fixed interval
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php <nowiki>Background LRU Writer/free list</nowiki>]
}}

{{TodoItem
|Consider whether increasing BM_MAX_USAGE_COUNT improves performance
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg01007.php <nowiki>Bgwriter LRU cleaning: we've been going at this all wrong</nowiki>]
}}

{{TodoItem
|Test to see if calling PreallocXlogFiles() from the background writer will help with WAL segment creation latency
* [http://archives.postgresql.org/pgsql-patches/2007-06/msg00340.php <nowiki>Re: Load Distributed Checkpoints, final patch</nowiki>]
}}

== Concurrent Use of Resources ==

{{TodoItem
|Do async I/O for faster random read-ahead of data
|Async I/O allows multiple I/O requests to be sent to the disk with results coming back asynchronously.
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg00820.php <nowiki>Asynchronous I/O Support</nowiki>]
* [http://archives.postgresql.org/pgsql-performance/2007-09/msg00255.php <nowiki>Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00027.php <nowiki>There's random access and then there's random access</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-01/msg00170.php <nowiki>Bitmap index scan preread using posix_fadvise (Was: There's random access and then there's random access)</nowiki>]
The above patch is already applied as of 8.4, but it still remains to figure out how to handle plain indexscans effectively.
* [http://archives.postgresql.org//pgsql-hackers/2009-01/msg00806.php Problems with the patch submitted for posix_fadvise in index scans]
}}

{{TodoItem
|Experiment with multi-threaded backend for better I/O utilization
|This would allow a single query to make use of multiple I/O channels simultaneously. One idea is to create a background reader that can pre-fetch sequential and index scan pages needed by other backends. This could be expanded to allow concurrent reads from multiple devices in a partitioned table.}}

{{TodoItem
|Experiment with multi-threaded backend for better CPU utilization
|This would allow several CPUs to be used for a single query, such as for sorting or query execution.
* http://archives.postgresql.org/pgsql-hackers/2008-10/msg00945.php
}}

{{TodoItem
|SMP scalability improvements
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00439.php <nowiki>Straightforward changes for increased SMP scalability</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00206.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00361.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]
}}

== TOAST ==

{{TodoItem
|Allow user configuration of TOAST thresholds
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00213.php <nowiki>Re: Proposed adjustments in MaxTupleSize and toastthresholds</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00082.php <nowiki>pg_lzcompress strategy parameters</nowiki>]
}}

{{TodoItem
|Reduce unnecessary cases of deTOASTing
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00895.php <nowiki>Re: [PATCHES] Eliminate more detoast copies for packed varlenas</nowiki>]
}}

{{TodoItem
|Reduce costs of repeat de-TOASTing of values
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg01096.php <nowiki>WIP patch: reducing overhead for repeat de-TOASTing</nowiki>]
}}

== Miscellaneous Performance ==

{{TodoItem
|Use mmap() rather than SYSV shared memory or to write WAL files?
|This would remove the requirement for SYSV SHM but would introduce portability issues. Anonymous mmap (or mmap to /dev/zero) is required to prevent I/O overhead.}}

{{TodoItem
|Consider mmap()'ing files into a backend?
|Doing I/O to large tables would consume a lot of address space or require frequent mapping/unmapping. Extending the file also causes mapping problems that might require mapping only individual pages, leading to thousands of mappings. Another problem is that there is no way to _prevent_ I/O to disk from the dirty shared buffers so changes could hit disk before WAL is written.}}

{{TodoItem
|Add a script to ask system configuration questions and tune postgresql.conf}}

{{TodoItem
|Consider ways of storing rows more compactly on disk:
* Reduce the row header size?
* Consider reducing on-disk varlena length from four bytes to two because a heap row cannot be more than 64k in length}}

{{TodoItem
|Consider transaction start/end performance improvements
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00948.php <nowiki>Reducing Transaction Start/End Contention</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00361.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]
}}

{{TodoItem
|Allow configuration of backend priorities via the operating system
|Though backend priorities make priority inversion during lock waits possible, research shows that this is not a huge problem.
* [http://archives.postgresql.org/pgsql-general/2007-02/msg00493.php <nowiki>Priorities for users or queries?</nowiki>]
}}

{{TodoItem
|Consider increasing the minimum allowed number of shared buffers
* [http://archives.postgresql.org/pgsql-bugs/2008-02/msg00157.php <nowiki>Re: [PATCH] Don't bail with legitimate -N/-B options</nowiki>]
}}

{{TodoItem
|Consider if CommandCounterIncrement() can avoid its AcceptInvalidationMessages() call
* [http://archives.postgresql.org/pgsql-committers/2007-11/msg00585.php <nowiki>pgsql: Avoid incrementing the CommandCounter when</nowiki>]
}}

{{TodoItem
|Consider Cartesian joins when both relations are needed to form an indexscan qualification for a third relation
* [http://archives.postgresql.org/pgsql-performance/2007-12/msg00090.php <nowiki>Re: TB-sized databases</nowiki>]
}}

{{TodoItem
|Consider not storing a NULL bitmap on disk if all the NULLs are trailing
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00624.php <nowiki>Proposal for Null Bitmap Optimization(for Trailing NULLs)</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2007-12/msg00109.php <nowiki>Re: [HACKERS] Proposal for Null Bitmap Optimization(for TrailingNULLs)</nowiki>]
}}

{{TodoItem
|Sort large UPDATE/DELETEs so it is done in heap order
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg01119.php <nowiki>Possible future performance improvement: sort updates/deletes by ctid</nowiki>]
}}

{{TodoItem
|Allow one transaction to see tuples using the snapshot of another transaction
|This would assist multiple backends in working together.
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00400.php <nowiki>Transaction Snapshot Cloning</nowiki>]
}}

{{TodoItem
|Consider decreasing the I/O caused by updating tuple hint bits
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00847.php <nowiki>Hint Bits and Write I/O</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00199.php <nowiki>Re: [HACKERS] Hint Bits and Write I/O</nowiki>]
}}

== Miscellaneous Other ==

{{TodoItem
|Deal with encoding issues for filenames in the server filesystem
* {{MessageLink|20090413184335.39BE.52131E4D@oss.ntt.co.jp|a proposed patch here}}
* {{MessageLink|8484.1244655656@sss.pgh.pa.us|some issues about it here}}
* {{MessageLink|20100107103740.97A5.52131E4D@oss.ntt.co.jp|Windows-specific patch here}}
}}

{{TodoItem
|Deal with encoding issues in the output of localeconv()
* [http://archives.postgresql.org/message-id/40c6d9160904210658y590377cfw6dbbecb53d2b8be0@mail.gmail.com bug report]
* [http://archives.postgresql.org/message-id/49EF8DA0.90008@tpf.co.jp draft patch]
* [http://archives.postgresql.org/message-id/21710.1243620986@sss.pgh.pa.us review of patch]
}}

{{TodoItem
|Provide schema name and other fields available from SQL GET DIAGNOSTICS in error reports
* [http://archives.postgresql.org/message-id/dcc563d10810211907n3c59a920ia9eb7cd2a6d5ea58@mail.gmail.com <nowiki>How to get schema name which violates fk constraint</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2009-11/msg00846.php
* {{MessageLink|3191.1263306359@sss.pgh.pa.us|Re: NOT NULL violation and error-message}}
* http://archives.postgresql.org/pgsql-hackers/2009-08/msg00213.php
}}

== Source Code ==

{{TodoItem
|Add use of 'const' for variables in source tree}}

{{TodoItem
|Move some things from contrib into main tree}}

{{TodoItemEasy
|Remove warnings created by -Wcast-align}}

{{TodoItem
|Move platform-specific ps status display info from ps_status.c to ports}}

{{TodoItem
|Add optional CRC checksum to heap and index pages
|One difficulty is how to prevent hint bit changes from affecting the computed CRC checksum.
* http://archives.postgresql.org/message-id/19934.1226601952%40sss.pgh.pa.us
* http://archives.postgresql.org/pgsql-hackers/2008-10/msg00002.php
* http://archives.postgresql.org/pgsql-hackers/2008-10/msg01028.php
* http://archives.postgresql.org/pgsql-hackers/2008-11/msg00524.php
* http://archives.postgresql.org/pgsql-hackers/2008-12/msg01101.php
* http://archives.postgresql.org/pgsql-hackers/2009-12/msg00011.php
}}

{{TodoItem
|Improve documentation to build only interfaces}}

{{TodoItem
|Allow cross-compiling by generating the zic database on the target system}}

{{TodoItem
|Improve NLS maintenance of libpgport messages linked onto applications}}

{{TodoItem
|Improve the module installation experience (/contrib, etc)
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg00132.php <nowiki>modules</nowiki>]
* {{messageLink|ca33c0a30807231640n6fb4035dod8121a18aa1fa29c@mail.gmail.com|Re: PostgreSQL extensions packaging}}
* {{messageLink|ca33c0a30804061349s41b4d8fcsa9c579454b27ecd2@mail.gmail.com|Database owner installable modules patch}}
* http://archives.postgresql.org//pgsql-hackers/2009-03/msg00855.php
* http://archives.postgresql.org/pgsql-hackers/2009-05/msg00912.php
}}

{{TodoItem
|Use UTF8 encoding for NLS messages so all server encodings can read them properly}}

{{TodoItemDone
|Update Bonjour to work with newer cross-platform SDK
* [http://archives.postgresql.org/pgsql-hackers/2006-09/msg02238.php <nowiki>Darwin stuff is getting deprecated</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2006-10/msg00048.php <nowiki>Use dns_sd.h for Bonjour</nowiki>]
}}

{{TodoItem
|Allow creation of universal binaries for Darwin
* http://archives.postgresql.org/pgsql-hackers/2008-07/msg00884.php
}}

{{TodoItem
|Consider GnuTLS if OpenSSL license becomes a problem
* [http://archives.postgresql.org/pgsql-patches/2006-05/msg00040.php <nowiki>[PATCH] Add support for GnuTLS</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg01213.php <nowiki>TODO: GNU TLS</nowiki>]
}}

{{TodoItem
|Consider making NAMEDATALEN more configurable in future releases}}

{{TodoItem
|Research use of signals and sleep wake ups
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00003.php <nowiki>Restartable signals 'n all that</nowiki>]
}}

{{TodoItemDone
|Add automated check for invalid C++ source code constructs
* [http://archives.postgresql.org/pgsql-patches/2007-07/msg00056.php <nowiki>Re: SPI-header-files safe for C++-compiler</nowiki>]
}}

{{TodoItem
|Allow C++ code to more easily access backend code
* http://archives.postgresql.org/pgsql-hackers/2008-12/msg00302.php
}}

{{TodoItem
|Consider simplifying how memory context resets handle child contexts
* [http://archives.postgresql.org/pgsql-patches/2007-08/msg00067.php <nowiki>Re: Memory leak in nodeAgg</nowiki>]
}}

{{TodoItem
|Create three versions of libpgport to simplify client code
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00154.php <nowiki>8.4 TODO item: make src/port support libpq and ecpg directly</nowiki>]
}}

{{TodoItem
|Improve detection of shared memory segments being used by others by checking the SysV shared memory field 'nattch'
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00656.php <nowiki>postgresql in FreeBSD jails: proposal</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00673.php <nowiki>Re: postgresql in FreeBSD jails: proposal</nowiki>]
}}

{{TodoItem
|Implement the non-threaded Avahi service discovery protocol
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00939.php <nowiki>Re: [PATCHES] Avahi support for Postgresql</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-02/msg00097.php <nowiki>Re: Avahi support for Postgresql</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg01211.php <nowiki>Re: [PATCHES] Avahi support for Postgresql</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-04/msg00001.php <nowiki>Re: [HACKERS] Avahi support for Postgresql</nowiki>]
}}

{{TodoItem
|Fix system views like pg_stat_all_tables to use set-returning functions, rather than views of per-column functions}}

{{TodoItemDone
|Allow table and index WITH options to be specified via hooks, for use with plugins like GiST index methods
* {{MessageLink|20090105171428.77B29754A17@cvs.postgresql.org|Change the reloptions machinery to use a table-based parser}}
}}

{{TodoItem
|Reduce data row alignment requirements on some 64-bit systems
* http://archives.postgresql.org/pgsql-hackers/2008-10/msg00369.php
}}

{{TodoItem
|Add support for returning multiple result sets?
* http://archives.postgresql.org/pgsql-general/2008-10/msg00454.php
}}

{{TodoItem
|Restructure TOAST internal storage format for greater flexibility
* http://archives.postgresql.org/pgsql-hackers/2008-11/msg00049.php
}}

{{TodoItemDone
|Allow setting of system oids during object creation, for use by pg_migrator
* http://archives.postgresql.org/pgsql-hackers/2009-08/msg00401.php
}}

=== Documentation ===
{{TodoSubsection}}

{{TodoItem
|Convert single quotes to apostrophes in the PDF documentation
* [http://archives.postgresql.org/pgsql-docs/2007-12/msg00059.php <nowiki>SGML docs and pdf single-quotes</nowiki>]
}}

{{TodoItem
|Provide a manpage for postgresql.conf
* {{messageLink|20080819194311.GH4428@alvh.no-ip.org|A smaller default postgresql.conf}}
* {{messageLink|200808211910.37524.peter_e@gmx.net|A smaller default postgresql.conf}}
}}

{{TodoItem
|Change the manpage-generating toolchain to use the new XML-based docbook2x tools
* {{messageLink|200808211910.37524.peter_e@gmx.net|A smaller default postgresql.conf}}}}

{{TodoItem
|Consider changing documentation format from SGML to XML
* [http://archives.postgresql.org/pgsql-docs/2006-12/msg00152.php <nowiki>Re: Authoring Tools WAS: Switching to XML</nowiki>]
}}

{{TodoEndSubsection}}

=== Windows ===
{{TodoSubsection}}

{{TodoItem
|Remove configure.in check for link failure when cause is found}}

{{TodoItem
|Remove readdir() errno patch when runtime/mingwex/dirent.c rev 1.4 is released}}

{{TodoItem
|Allow psql to use readline once non-US code pages work with backslashes}}

{{TodoItem
|Fix problem with shared memory on the Win32 Terminal Server}}

{{TodoItemDone
|Diagnose problem where shared memory can sometimes not be attached by postmaster children
* [http://archives.postgresql.org/pgsql-general/2007-08/msg01377.php <nowiki>FATAL: could not reattach to shared memory (Win32)</nowiki>]
* [http://archives.postgresql.org/message-id/13271.1241561721@sss.pgh.pa.us <nowiki>Re: "could not reattach to shared memory" captured in buildfarm</nowiki>]
}}

{{TodoItem
|Improve signal handling
* [http://archives.postgresql.org/pgsql-patches/2005-06/msg00027.php <nowiki>Simplify Win32 Signaling code</nowiki>]
}}

{{TodoItem
|Convert MSVC build system to remove most batch files
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00961.php <nowiki>MSVC build system</nowiki>]
}}

{{TodoItem
|Support pgxs when using MSVC}}

{{TodoItem
|Fix MSVC NLS support, like for to_char()
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00485.php <nowiki>NLS on MSVC strikes back!</nowiki>]
* [http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php <nowiki>Fix for 8.3 MSVC locale (Was [HACKERS] NLS on MSVC strikes back!)</nowiki>]
}}

{{TodoItem
|Find a correct rint() substitute on Windows
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00808.php <nowiki>Minor bug in src/port/rint.c</nowiki>]
}}

{{TodoItemDone
|Reduce compiler warnings on 64-bit Windows
* http://archives.postgresql.org/pgsql-hackers/2008-07/msg00437.php
* http://archives.postgresql.org/pgsql-hackers/2008-07/msg00440.php }}

{{TodoItem
|Fix global namespace issues when using multiple terminal server sessions
* [http://archives.postgresql.org/message-id/48F3BFCC.8030107@dunslane.net problems with Windows global namespace]}}

{{TodoItem
|Change from the current autoconf/gmake build system to cmake
* http://archives.postgresql.org/pgsql-hackers/2008-12/msg01869.php
}}

{{TodoItem
|Improve consistency of path separator usage
* http://archives.postgresql.org/message-id/49C0BDC5.4010002@hagander.net
}}

{{TodoItemDone
|Allow compilation using MSVC 2008
* http://archives.postgresql.org/pgsql-general/2009-08/msg01172.php
}}

{{TodoEndSubsection}}

=== Wire Protocol Changes ===
{{TodoSubsection}}

{{TodoItem
|Allow dynamic character set handling}}

{{TodoItem
|Add decoded type, length, precision}}

{{TodoItem
|Use compression?}}

{{TodoItem
|Update clients to use data types, typmod, schema.table.column names of result sets using new statement protocol}}

{{TodoEndSubsection}}

== Exotic Features ==

{{TodoItem
|Add pre-parsing phase that converts non-ISO syntax to supported syntax
|This could allow SQL written for other databases to run without modification.}}

{{TodoItem
|Allow plug-in modules to emulate features from other databases}}

{{TodoItem
|Add features of Oracle-style packages
|A package would be a schema with session-local variables, public/private functions, and initialization functions. It is also possible to implement these capabilities in any schema and not use a separate "packages" syntax at all.
* [http://archives.postgresql.org/pgsql-hackers/2006-08/msg00384.php <nowiki>proposal for PL packages for 8.3.</nowiki>]
}}

{{TodoItem
|Consider allowing control of upper/lower case folding of unquoted identifiers
* [http://archives.postgresql.org/pgsql-hackers/2004-04/msg00818.php <nowiki>Bringing PostgreSQL torwards the standard regarding case folding</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg01527.php <nowiki>Re: [SQL] Case Preservation disregarding case sensitivity?</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00849.php <nowiki>TODO Item: Consider allowing control of upper/lower case folding of unquoted, identifiers</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00415.php <nowiki>Identifier case folding notes</nowiki>]
* http://archives.postgresql.org/pgsql-hackers/2008-07/msg00415.php
}}

{{TodoItem
|Add autonomous transactions
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00893.php <nowiki>autonomous transactions</nowiki>]
}}

{{TodoItem
|Give query progress indication
* [[Query progress indication]]
}}

{{TodoItem
|Rethinking our type system
* [[Rethinking datatypes]]
}}

== Features We Do ''Not'' Want ==

{{TodoItem
|All backends running as threads in a single process (not wanted)
|This eliminates the process protection we get from the current setup. Thread creation is usually the same overhead as process creation on modern systems, so it seems unwise to use a pure threaded model, and MySQL and DB2 have demonstrated that threads introduce as many issues as they solve. Threading specific operations such as I/O, seq scans, and connection management has been discussed and will probably be implemented to enable specific performance features. Moving to a threaded engine would also require halting all other work on PostgreSQL for one to two years.}}

{{TodoItem
|Optimizer hints (not wanted)
|Optimizer hints are used to work around problems in the optimizer and introduce upgrade and maintenance issues. We would rather have the problems reported and fixed. We have discussed a more sophisticated system of per-class cost adjustment instead, but a specification remains to be developed.
* [http://archives.postgresql.org/pgsql-hackers/2006-08/msg00506.php <nowiki>Re: An Idea for planner hints</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg00517.php <nowiki>Index Tuning Features</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg00663.php <nowiki>Re: [PERFORM] Hints proposal</nowiki>]
}}

{{TodoItem
|Embedded server (not wanted)
|While PostgreSQL clients runs fine in limited-resource environments, the server requires multiple processes and a stable pool of resources to run reliably and efficiently. Stripping down the PostgreSQL server to run in the same process address space as the client application would add too much complexity and failure cases. Besides, there are several very mature embedded SQL databases already available.}}

{{TodoItem
|Obfuscated function source code (not wanted)
|Obfuscating function source code has minimal protective benefits because anyone with super-user access can find a way to view the code. At the same time, it would greatly complicate backups and other administrative tasks. To prevent non-super-users from viewing function source code, remove SELECT permission on pg_proc.
* http://archives.postgresql.org/pgsql-general/2008-09/msg00668.php
}}

</div>

[[Category:Todo]]

GSoC 2010

2010-02-25T06:50:07Z

Mastermind: /* Past Success */

== Key Info ==
* March 8th - 12th, Mentoring Application Due
* March 29th - April 9th, Student Applications Due

* [http://socghop.appspot.com/ GSOC 2010 Home page ]
* [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs GSOC 2010 FAQ]
* [http://www.postgresql.org/developer/summerofcode Postgres GSOC Page, Needs Updating!]

== Stuff to do: ==

== FInd Admins ==
* Robert Treat - Past mentor 2x and co-admin
* Selena Deckelmann - Co-admin, Mentor Summit attendee.

== Find Mentors ==
* Dave Page - Former mentor - pgAdmin, Windows, Packaging, Infrastructure
* Robert Haas - CommitFest Manager
* Gerd Koenig

== Past Success ==
* Florian - read-only on snapshots, no advancement of xid on select statements
* Ivan - Full-Text Support in phpPgAdmin
* Mickael Deloison - pgScript engine for pgAdmin
* Luis Alberto Ochoa Paz - Graphical query builder for pgAdmin
more?

== GOALS: ==
* usable code
** useful/novel ideas
** research projects

* longer term contributors

== TODOs: ==

* Kick-off Meeting for Community Members
* Update GSOC page
* Advertising?
* Blog that we're participating and seeking students
* Round of private emails to people who have participated in the past: Heikki, Simon, Mark,
** request interest, and then follow up in asking about possible topics for students
* Mentor recruitment and then email to -hackers
** do this much later when we have some proposals in?

* Recruitment -- no organized group effort?
** -announce, -general, -hackers
** user group lists
** phppgadmin/pgadmin
** berkeley
** Univ. of Maryland -- contact them?

* Identify the commitfest that the code will be submitted to

== Expectations ==

* Stuff to keep students together:
** Regular blogging from students
** weekly group IRC checkin? -- two checkin times maybe?

* Have students communicate on -hackers where appropriate (didn't really work?)
** Or other relevant -devel lists

* Mailing list
** pgsql-students (?) vs. -hackers (?) maybe up to mentor?
** mentors mailing list -admin mailing list, berkus said?
** students mailing list via gsoc

[[Category:Google Summer of Code]]

Jabber

2010-02-25T06:49:00Z

Mastermind: there is no such thing as proxy.eu.postgresql.org

== Jabber Server ==

If you have an account on the community jabber server with Pidgin, make sure to use:

* Advanced
** Require SSL/TLS checked
** Force old (port 5223) SSL checked
** Allow plaintext auth over unencrypted screens unchecked
** Connection port: 5223
** Connect Server: jabber.postgresql.org
** File transfer proxies: <not needed>

Category:PostgreSQL 9.0

2010-02-21T18:02:11Z

Mastermind: 9.0

All things related to PostgreSQL 9.0

85AlphaFeatures

2010-02-21T17:57:36Z

Mastermind:

This page contains a list of features, for publication for each alpha release.

== Alpha1 ==

=== SQL ===

* DROP COLUMN and DROP CONSTRAINT now support an IF EXISTS clause so that you can avoid errors when running repeatable scripts.
* UNIQUE constraints can now be DEFERRABLE

=== Performance ===

* GEQO generic algorithm query plans, for very complex queries, can be made repeatable by setting a geqo_seed. This will help with debugging bad plans generated by GEQO.

=== Stored Procedures / Functions ===

=== Administration and Monitoring ===

* You may now display the SQLSTATE error code as part of the log_line_prefix in your log by using the %e switch.

=== Tools ===

* pg_standby no longer links to a specific libpq version, preventing unnecessary incompatibility issues.
* pgbench is now multi-threaded, allowing it to use multiple CPU's for its client connections.

=== psql ===

* The \d+ describe table shortcut now shows the child tables which inherit from the specified table.
* The \di index describe command now shows the index method.

=== Other ===

* We have change the names of some internal functions to remove conflicts with C++ reserved words. This will make it easier to plug-in C++ code to the PostgreSQL codebase.

[[Category:PostgreSQL 9.0]]

DefaultACL

2010-02-21T17:56:54Z

Mastermind: 8.5->9.0

This project has been mostly completed in PostgreSQL 9.0.
See also:
* [http://developer.postgresql.org/pgdocs/postgres/sql-grant.html GRANT] / [http://developer.postgresql.org/pgdocs/postgres/sql-revoke.html REVOKE] IN SCHEMA
* [http://developer.postgresql.org/pgdocs/postgres/sql-alterdefaultprivileges.html ALTER DEFAULT PRIVILEGES]
* [http://developer.postgresql.org/pgdocs/postgres/catalog-pg-default-acl.html pg_default_acl]

== Description ==
On the TODO we have:

Allow GRANT/REVOKE permissions to be inherited by objects based on schema permissions

This is a proposal for implementation of default ACLs/permissions for newly created objects.
This will only be at object creation time (there is a separate TODO item for doing grant/revoke
on multiple objects at once using globbing or similar; if I make a proposal on that it'll be
another wiki page).

== Why to Do This ==

Managing permissions for a large complex database is very labor-intensive. DBAs are forced to use GUI tools or ad-hoc scripts which are awkward and or error-prone. As a result, many DBAs avoid creating and maintaining proper role setups at all and run insecure databases. We get requests for better permissions management for new databases at least 5 times a week on IRC.

Allowing DBAs to set up default permissions for new objects would greatly simplify the task of implementing a database role setup. It's also a baby step towards having more sophisticated role-based management tools.

== People ==
Folks currently involved in design and implementation:

Stephen Frost - Project lead, developed catalog changes patch
Emilie Giustozzi - Working on grammar changes
Josh Berkus - Consulting on design & grammar, helping with the wiki
Petr Jelinek - Initial gram.y patch, most of coding
Simon Riggs - usability review

== Catalog ==

New pg_catalog table: [ [[Media:Nspdefacl_catalog.patch.gz|patch]] ] [ [[Media:Nspdefacl_catalog.uni.patch.gz|Unified patch]] ]

pg_namespace_default_acl (names can be changed to protect the innocent)
defaclnamespace - OID of the schema
defaclgrantobjtype - Grantable object kind, char(1) similar to relkind but for all
types of grantable objects; this is already defined in an enum
in parsenodes.h: GrantObjectType or some such
'r' - table
'v' - view
'f' - function
'S' - sequence
'C' - column
-- Probably can't support this, to be honest. It would imply knowing
that all tables created have the column(s) referenced, and would cause
errors most likely if the column wasn't there, which isn't good.
'l' - language
'W' - foreign-data wrapper
'F' - foreign server
defacllist[] - array of acls that the object should have on creation
this is NOT a mask, it's exactly what the object will get, in
other words, the default PG perms are ignored if this is
a def_acl in here for that schema/obj_kind
This will look like a regular list of perms, eg:
{role1=arwd/sfrost,role2=r/sfrost}
Full row examples:
2200, 'r', '{role1=arwd/sfrost,role2=r/sfrost}'
2200, 'v', '{role1=r/sfrost,role2=r/sfrost}'

== Syntax ==

Current (as of 2009-07-14) wip patch: [ [[Media:Defaultacls.diff.gz]] ]

Current syntax is implemented based on Josh's ideas with few minor adjustments.

Simple syntax:

ALTER SCHEMA blah SET DEFAULT PRIVILEGES ON TABLE SELECT TO public;
ALTER SCHEMA blah SET DEFAULT PRIVILEGES ON TABLE SELECT TO webuser,admin AND UPDATE to admin AND INSERT to admin AND DELETE to admin;
ALTER SCHEMA blah ADD DEFAULT PRIVILEGES ON TABLE INSERT TO webuser;
ALTER SCHEMA blab DROP DEFAULT PRIVILEGES ON TABLE DELETE FROM admin;

Multiple privileges to multiple users:

ALTER SCHEMA blah SET DEFAULT PRIVILEGES ON TABLE SELECT to webuser,admin AND UPDATE,INSERT,DELETE to admin;

And most complex syntax with multiple different privileges on different objects to multiple users:

ALTER SCHEMA blah SET DEFAULT PRIVILEGES
ON TABLE SELECT TO webuser,admin AND UPDATE,INSERT,DELETE TO admin
ON VIEW SELECT TO webuser,admin;

== Syntax suggestions ==

New syntax added to ALTER SCHEMA to support this
Note:
Not using grant/revoke terms (or those commands for that matter)
because it implies something is actually going to happen for existing
objects, which isn't true. This is only for new objects which are
being created
All of this is subject to acceptance by gram.y, of course.

Suggestion #1:

ALTER SCHEMA blah SET DEFAULT ACL TABLE select to role1,role2
TABLE insert to role2
VIEW select to role1;
Suggestion #2: Probably better
Force types to be done seperately and reorder things:
ALTER SCHEMA blah SET DEFAULT TABLE ACL select to role1,role2
ACL insert to role2;
ALTER SCHEMA blah SET DEFAULT VIEW ACL select to role1;
Also allow using all for either side (priv list or role list):
ALTER SCHEMA blah DROP DEFAULT VIEW ACL all from role1;
ALTER SCHEMA blah DROP DEFAULT TABLE ACL select from all;
ALTER SCHEMA blah ADD DEFAULT TABLE ACL all TO role1;
All for 'ADD' implies public, below mean the same
ALTER SCHEMA blah ADD DEFAULT TABLE ACL SELECT TO all;
ALTER SCHEMA blah ADD DEFAULT TABLE ACL SELECT TO public;

Suggestion #3:

(Josh Berkus) I'd prefer a syntax which is more natural language, provided we can get gram.y to support it. Also, I think "ACL" as a keyword is confusing, compared to "permissions" which is both clearer and less likely to be the name of a user DB object.

ALTER SCHEMA blah SET DEFAULT PERMISSIONS ON TABLE SELECT TO public;
ALTER SCHEMA blah SET DEFAULT PERMISSIONS ON TABLE SELECT TO webuser,admin AND UPDATE to admin AND INSERT to admin AND DELETE to admin;
ALTER SCHEMA blah ADD DEFAULT PERMISSIONS ON TABLE INSERT TO webuser;
ALTER SCHEMA blab DROP DEFAULT PERMISSIONS ON TABLE DELETE FROM admin;

Punctuation could vary according to what gram.y will tolerate. If it's happy with the below, this would be even better:

ALTER SCHEMA blah SET DEFAULT PERMISSIONS ON TABLE SELECT to webuser,admin AND UPDATE,INSERT,DELETE to admin;

We might also be able to do:

ALTER SCHEMA blah SET DEFAULT PERMISSIONS
ON TABLE SELECT TO webuser,admin AND UPDATE,INSERT,DELETE TO admin
AND ON VIEW SELECT TO webuser,admin;

Suggestion #4:

(What we're really going to do)
Basically, Josh's suggestion is where we're headed at the moment. Emilie Giustozzi is working on the gram.y changes to implement it.
As she correctly pointed out, we will be using PRIVILEGES instead of PERMISSIONS, as PRIVILEGES is already either a key or semi-key word
in PG.

Suggestion #5:

(gsmet) I find the "ON TABLE SELECT" part of the proposed syntaxes confusing.

I would prefer a syntax which mimics the GRANT syntax:

ALTER SCHEMA blah SET DEFAULT PRIVILEGES GRANT SELECT ON TABLE TO webuser;
ALTER SCHEMA blah SET DEFAULT PRIVILEGES GRANT UPDATE, INSERT ON TABLE TO admin, superadmin;

Or without the GRANT keyword:

ALTER SCHEMA blah SET DEFAULT PRIVILEGES SELECT ON TABLE TO webuser;
ALTER SCHEMA blah SET DEFAULT PRIVILEGES UPDATE, INSERT ON TABLE TO admin, superadmin;

Simon says: we should use PRIVILEGE rather than plural if we do this

Suggestion #6

If we have an ALTER SCHEMA command for this, then users will need to issue both a GRANT to change existing tables and an ALTER SCHEMA to change new tables. It seems more natural to seek a single command that will change the privilege for new and existing tables.

So, I suggest

GRANT .... ON SCHEMA ..... [WITH DEFAULT OPTION];

So we set existing tables with a GRANT and we set existing *and* new tables with a GRANT ON ALL ... WITH DEFAULT OPTION.
That is easier to use since it is a single command, few extra syntax to learn and easier docs/more centralised. It also extends GRANT in a similar way to the extensions suggested for GRANT ALL.

The same concept can then be easily extended to other object types, if need be.

We also need the ability to set the default back to "no default" when required.

REVOKE DEFAULT OPTION FOR ..... ON SCHEMA ....

PJMODOS says:@Simon I remember Tom saying GRANT should not affect any future privileges, that was the whole reason why we used ALTER SCHEMA. Also your way does not allow us to grant only on new objects without affecting existing ones.

== Additional Ideas ==

Suggestion #3:
Maybe also support syntax to implement the default ACL for an
object, this would wholesale replace the existing perms, eg:

ALTER TABLE blah SET DEFAULT ACL;
Alternatively, for the arguments above, perhaps have GRANT syntax
support this general capability, eg:
GRANT DEFAULT ON TABLE blah;

Also support ADD/DROP default acl to allow adding to and deleting from the
def_acls[] list so you don't always have to specify the entire list. If
'set' is used, then everything will be replaced by whatever is provided.

Possible syntax for ownership
This will probably be implemented separately as there is some
concern about security. Intent is to implement this as
essentially a 'ALTER TABLE blah OWNER TO role1;' as the user
creating the table, so they will need the same perms they
need to do that to begin with. This is just a convenience
mechanism, not a change in what people are allowed to do.
Should mean that you need to be a member of the role you're
changing the ownership to, and that role need CREATE rights
on the schema.
ALTER SCHEMA blah ADD DEFAULT TABLE OWNER role1;

Suggestion #4:
Support defaults attached to the creating user rather than the
schema that the object is created in. For instance:
ALTER USER webuser_admin SET DEFAULT PRIVILEGES SELECT ON TABLE TO webuser_read_only;
would mean that all tables created by webuser_admin would
grant privileges for SELECT to webuser_read_only.

== Privilege ==

Setting the default privilege for a Schema may require a separate privilege also. This will allow DBAs to grant the ability for users to create tables yet prevent them from changing the underlying administrative structure.

We would need to define a default owner for new objects. This would then be equivalent to running REASSIGN OWNED BY current_role TO default_role; immediately after a table is created.

[[Category:PostgreSQL 9.0]]

PostgreSQL 9.0 Open Items

2010-02-21T17:55:07Z

Mastermind:

== Bugs ==
* {{messageLink|603c8f071001041055j4a8fca2egbe438da50f0e0599@mail.gmail.com|<nowiki>missing need_initialization = false in reloptions code</nowiki>}}
* [http://archives.postgresql.org/pgsql-bugs/2009-12/msg00267.php COPY staments with paths containing non-ASCII characters under WinXP]
* [http://archives.postgresql.org/pgsql-bugs/2009-12/msg00145.php BUG #5245: Full Server Certificate Chain Not Sent to client]
* [http://archives.postgresql.org/pgsql-bugs/2009-10/msg00039.php incorrect exit code from psql with single transaction + violation of deferred FK constraint]
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg01297.php Standalone backends run StartupXLOG in an incorrect environment]
* [http://archives.postgresql.org/message-id/4253.1260163602@sss.pgh.pa.us Duplicative display of exclusion constraints in psql \d]

== Planned Further work ==

* [[Hot Standby TODO]] contains various items that need to be addressed for Hot Standby
* [http://wiki.postgresql.org/wiki/Streaming_Replication#v9.0 Streaming Replication TODO for v9.0] contains various items that need to be addressed.
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg00531.php Improve behavior of SUSET GUC variables added by loadable modules?]

== Security Issues ==

* {{messageLink|28907.1258157302@sss.pgh.pa.us|ALTER ROLE/DATABASE RESET ALL versus security}}

== At BETA time ==
* Send out summary of new features/changes to other projects e.g. send COPY changes to ETL vendors

= Resolved Issues =
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01926.php Hot Standby needs to fully support VACUUM FULL]
* [http://archives.postgresql.org/pgsql-bugs/2009-12/msg00078.php BUG #5236: Aparent bug in ecpg]
** rhaas says: [http://archives.postgresql.org/pgsql-bugs/2010-01/msg00077.php fixed by mmeskes]
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg00643.php AbortOutOfAnyTransaction within ProcessInterrupts is *utterly* unsafe]
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg01645.php Archive recovery broken on EXEC_BACKEND (win32)]
* [http://archives.postgresql.org/message-id/20090811111446.GA25965@depesz.com Poor handling of error cases for deferrable unique constraints]
* Replace ALTER TABLE ... SET STATISTICS DISTINCT with a general attribute-options facility
* [http://archives.postgresql.org/pgsql-bugs/2009-12/msg00274.php pg_listener entries deleted under heavy NOTIFY load only on Windows]
* [http://archives.postgresql.org/message-id/23761.1265596434@sss.pgh.pa.us B-tree dead page removal not safe with read-only transactions]
* [http://archives.postgresql.org/message-id/20702.1265306533@sss.pgh.pa.us Bogus handling of relcache init files during HS replay]
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01716.php Large object ownership and permissions are dumped incorrectly]

[[Category:PostgreSQL 9.0]]

Development information

2010-02-21T17:53:08Z

Mastermind: point to the 9.0 page

__NOTOC__
This area includes developer-targeted documentation regarding aspects of PostgreSQL development. Please visit the [http://www.postgresql.org/developer developer area] of the PostgreSQL website for more general information about the development of PostgreSQL. You can find most developers in [irc://irc.freenode.net/postgresql #postgresql on freenode]. A list of IRC nick names with their respective real world names can be found [[IRC2RWNames | here]].

==PostgreSQL 9.0 - Active Development==

* [http://commitfest.postgresql.org/action/commitfest_view/open Open CommitFest] - new patch submissions here
* [[Todo|Todo list]]
* [[Todo:Contents|Unofficial Todo Detail]]
* [[RRReviewers|Round-robin Patch Review]]
* [[Running a CommitFest]]
* [[Development projects]] - links to individual projects
* [[85AlphaFeatures|Alpha Release Feature List]]
* [[HowToBetaTest|HOWTO Alpha and Beta Test PostgreSQL]]
* [[PostgreSQL 9.0 Open Items]]

==PostgreSQL 8.4 - Maintenance==
* [https://commitfest.postgresql.org/ CommitFest]
* [[PostgreSQL 8.4 Development Plan]]
* [[Todo:WishlistFor84|Wishlist for 8.4]]
* [[Waiting for 8.4]] - commentary on commits
* [[PostgreSQL 8.4 Open Items]]
* [[84Beta2Changes|Beta 2 Major Changes List]]

== Developer Resources ==
* [[Developer FAQ]]
* [[Fixing shift/reduce conflicts in Bison]]
* [[Submitting a Patch]]
* [[Reviewing a Patch]]
* [[Regression test authoring]]
* [[Working with CVS]]
* [[Working with Git]]
* [[Working with Eclipse]] (using CVS)
* [http://www.postgresql.org/about/featurematrix Feature Matrix]
* [[PL Matrix|Procedural Language Matrix]]
* [http://developer.postgresql.org/pgdocs/postgres/index.html Development docs] (updated every 5 minutes)
* [[PgCon 2009 Developer Meeting]]
* [[PgCon 2008 Developer Meeting]]

[[Category:CommitFest]]

PostgreSQL 8.5 Open Items

2010-02-21T17:52:11Z

Mastermind: PostgreSQL 8.5 Open Items moved to PostgreSQL 9.0 Open Items: 8.5 is no more - per gripe from Tom on -hackers

#REDIRECT [[PostgreSQL 9.0 Open Items]]

PostgreSQL 9.0 Open Items

2010-02-21T17:52:10Z

Mastermind: PostgreSQL 8.5 Open Items moved to PostgreSQL 9.0 Open Items: 8.5 is no more - per gripe from Tom on -hackers

Aggregate Median

2009-12-09T19:51:35Z

Mastermind:

{{SnippetInfo|Aggregate Median|version=8.4|lang=SQL}}
[[Category:SQL]]
by Scott Bailey 'Artacus'

Unlike mode() and range(), this one will only work with PostgreSQL 8.4 and higher due to the dynamic limit and offset.

<source lang="sql">
CREATE OR REPLACE FUNCTION _final_median(numeric[])
RETURNS numeric AS
$$
SELECT AVG(val)
FROM (
SELECT val
FROM unnest($1) val
ORDER BY 1
LIMIT 2 - MOD(array_upper($1, 1), 2)
OFFSET CEIL(array_upper($1, 1) / 2.0) - 1
) sub;
$$
LANGUAGE 'sql' IMMUTABLE;

CREATE AGGREGATE median(numeric) (
SFUNC=array_append,
STYPE=numeric[],
FINALFUNC=_final_median,
INITCOND='{}'
);
</source>

=== See Also ===

[[Aggregate Mode]]
[[Aggregate Median]]

FrOSCon 2009

2009-08-31T18:18:06Z

Mastermind: small corrections

= FrOSCon 2009 =

The German PostgreSQL User Group attended the [[http://www.froscon.org FrOSCon 2009]] in St. Augustin, Germany, near Cologne. On Sunday we had our own devroom.

== Devroom Details ==

* '''When:''' Sunday, August 23, 2009
** 10:00am to 3:00pm

== Devroom Schedule ==

{| border="1"
!Time
!Talk
!Speaker
!Company
|-
| 10:00
| PostgreSQL & Performance
| Michael Renner
|
|-
| 11:00
| [[Media:Pg-8.4_Andreas_Scherbaum.pdf|Was gibt es neues in PostgreSQL 8.4]]
| Andreas Scherbaum
| Andreas Scherbaum
|-
| 12:00
| [[Media:Froscon09_pg_en_Stefan_Kaltenbrunner.pdf|postgresql.org - Die Projektinfrastruktur]]
| Stefan Kaltenbrunner
|
|-
| 13:00
| Testing Postgres with pgTap
| Rolf Schaufelberger
|
|-
| ab 14:00
| Lightning Talk: [[Media:Tophosting_lightning_Stefan_Kaltenbrunner.pdf|mandantenfähige ISP Hosting Plattform]]
| Stefan Kaltenbrunner
| conova communications GmbH
|-
| ab 14:00
| Lightning Talk: geizhals.at
| Michael Renner
| Preisvergleich Internet Services GmbH
|-
| ab 14:00
| Lightning Talk: Faseroptische Systeme
| Marek Swierzy + Andreas Scherbaum
| OSSCAD GmbH & Co. KG
|-
| ab 14:00
| Lightning Talk: [[Media: Pg-in-debian.org_Peter_Palfrader.pdf|PostgreSQL im Debian Projekt]]
| Peter Palfrader
|
|-
| ab 14:00
| Lightning Talk: [[Media:Neue_Usergroup_Webseite_Bjoern_Haeuser.pdf|die neue Usergroup Webseite]]
| Björn Häuser
| imos GmbH
|-
| ab 14:00
| Lightning Talk: [[Media:Lightning_talks_FrOSCon_2009_ChristianHofstaedtler_PuppetCM.pdf|Configuration Management using Puppet]]
| Christian Hofstädtler
| Inqnet GmbH
|-
| ab 14:00
| Lightning Talk: [[Media:Lightning_talks_FrOSCon_2009_Andreas_Scherbaum.pdf|Uniturm.de]]
| Andreas Scherbaum
| Andreas Scherbaum IT-Services
|-
| ab 14:00
| Lightning Talk: [[Media:Lightning_talks_FrOSCon_2009_Andreas_Scherbaum.pdf|urbanite.de]]
| Andreas Scherbaum
| Andreas Scherbaum IT-Services
|}

Performance QA Testing

2009-08-30T12:52:37Z

Mastermind: add some free datasets that could be used for benchmarking - inspired by http://ronaldbradford.com/blog/seeking-public-data-for-benchmarks-2009-08-28/

This page centralizes the efforts on performances QA testing: available hardware, available tools, continuous benchmarking effort...

The PostgreSQL Performance lab is being created to allow community members of the Open Source database [http://www.postgresql.org/ PostgreSQL] to have enterprise class hardware to test on.

The testing that will occur includes industry standard workloads such as OLTP, DSS and BI. Furthermore we will also use the hardware for other practical and customer oriented testing to improve scalability (processor utilization, i/o, load balancing, etc.) and managing large data sets (loading, backups, restores, replication, etc).

=== Donations ===

For donation inquiries, please contact [mailto:josh@postgresql.org Josh Berkus <josh @t postgresql.org>] and [mailto:jdrake@postgresql.org Joshua Drake <jdrake @t postgresql.org>].

=== Mailing List ===

There is a [http://lists.pgfoundry.org/mailman/listinfo/perflab-general mailing list] available to discuss administrative aspects of community equipment. Please continue to use the -hackers and -performance mailing lists for performance and technical discussions.

== QA platforms ==

* [[QA Platform hosted at Command Prompt]] - Portland, Oregon, USA
* [[QA Platform hosted at Open Wide (France)]]

== Tools ==

* Former OSDL work: [http://osdldbt.sourceforge.net/ Database Test Suite] and [http://crucible.svn.sourceforge.net/viewvc/crucible/ Web interface]
* [http://www.westnet.com/~gsmith/content/postgresql/pgbench-tools.htm pgbench-tools from Greg Smith]
* [http://bristlecone.continuent.org/HomePage Bristlecone from Continuent]
* [http://tsung.erlang-projects.org/ Tsung load injector] allows to define sessions (containing queries and thinktime, etc) and replay them with very high concurrency setup. Can use many loading nodes at a time, multi OS support (written in [http://www.erlang.org/ erlang], extensible in this language)
* [http://dim.tapoueh.org/temp/tsung-plotter/ Tsung Ploter] plots several tsung runs onto the same graphs set, for easy comparing. Uses python and matplotlib.
* Tsung DBT2 Implementation (tsung module in erlang), WIP, to get published asap.

== Ideas ==

* look into [http://sysbench.sourceforge.net/ sysbench] - it has some issues with locking on postgresql but at least read-only it seems to work fine

* collecting all the various small samples and testcases posted over the last few years on -performance, -hackers & -bugs and put them into a test set

* consider doing tests using pgbench -M (simple|extended|prepared) to catch regressions in one of those modes

* resurrect Jan Wiecks tpc-w implementation available on [http://pgfoundry.org/projects/tpc-w-php/ pgfoundry]

* add full text search benchmarking by using [http://www.sigaev.ru/cvsweb/cvsweb.cgi/ftsbench/ ftsbench] from teodor

* XML benchmarking ?

* investigate [http://advogato.org/person/nconway/diary.html?start=21 QuickCheck] and http://advogato.org/person/nconway/diary/23.html

* Implement the [http://www.cs.umb.edu/~poneil/StarSchemaB.PDF Star Schema Benchmark].

== Datasets ==

Some public datasets that could be used to get realistic data for various kind of benchmarks:

* [http://www.freebase.com/docs/data_dumps Freebase] - Various wiki style data on places/people/things - ~600MB compressed
* [http://www.imdb.com/interfaces#plain IMDB] - the IMDB database - see also http://code.google.com/p/imbi/
* [http://www.data.gov/ ] - US federal government data collection see also [http://www.sunlightlabs.com/ sunlightlabs]
* [http://wiki.dbpedia.org/Downloads DBpedia] - wikipedia data export project
* [http://linux.dell.com/dvdstore/ Dell DVDstore] - Dells DVD Store context data
* [http://www.eoddata.com/ eoddata] - historic stock market data (requires reigstration - licence?)
* [http://www.transtats.bts.gov/Tables.asp?DB_ID=120&DB_Name=Airline%20On-Time%20Performance%20Data&DB_Short_Name=On-Time RITA] - Airline On-Time Performance Data
* [http://wiki.openstreetmap.org/wiki/Planet.osm Openstreetmap] - Openstreetmap source data

== Information ==
* [http://wiki.postgresql.org/wiki/Performance_Optimization In depth performance articles on PostgreSQL]
* [http://wiki.postgresql.org/wiki/HP_ProLiant_DL380_G5_Tuning_Guide DL380 Tuning Guide]
* [http://www.vimeo.com/channels/postgres Videos on Performance and other topics]
* [http://www.commandprompt.com/blogs/joshua_drake/2008/04/is_that_performance_i_smell_ext2_vs_ext3_on_50_spindles_testing_for_postgresql/ Performance measurements between load and filesystems (Linux)]

Category talk:Software Ports

2009-08-06T18:24:04Z

Mastermind: /* Bitweaver */ new section

If there is no objection I would like to add Bitweaver to this page.

Many of the lead developers use postgres exclusively. It is fully supported in Bitweaver and sets this project apart from most of the Top 10 at WikiMatrix.

http://bitweaver.org ranks 10th in the WikiMatrix Top 25 most popular wiki CMS.

Features that set Bitweaver apart among the Top 10 include:

Customize Without Fear
Thanks to highly modular and easily extensible design

Speed from end-to-end
From schema design, query utilization, to software design

Style Made Easy
Standard compliant XHTML Strict 1.0 and sophisticated tableless CSS

Datastorage
MySQL, PostgreSQL, Oracle, and Firebird

Extras
Blog, Calendar, Image and File Galleries, Forums, Groups, Tags

== Bitweaver ==

seems reasonable - just add it :)