PostgreSQL wiki - User contributions [en]

Foreign data wrappers

2013-05-25T22:59:32Z

Dfetter: /* NoSQL Databases Wrappers */

= Foreign Data Wrappers =
In 2003, a new extension called [[SQL/MED]] ("SQL Management of External Data") was added to the SQL standard. It is a standardized way of handling access to remote objects in SQL databases. In 2011, PostgreSQL 9.1 was released with a great support of this standard.

In a nutshell, you can now use various Foreign Data Wrappers (FDW) to connect a PostgreSQL Server to remote data stores. This page is an incomplete list of the Wrappers available right now. Another [http://pgxn.org/tag/fdw/ fdw list] can be found at [http://pgxn.org/ the PGXN website].

The information about how to write a FDW can be found [http://www.postgresql.org/docs/9.2/static/fdwhandler.html here].

Please keep in mind that most of these wrappers are '''not officially supported by the PostgreSQL Global Development Group''' (PGDG) and that some of these projects are '''still in Beta''' version. Use carefully!

== SQL Databases Wrappers ==

===oracle_fdw===
* [http://pgfoundry.org/projects/oracle-fdw/ source code]
* [http://pgxn.org/dist/oracle_fdw/ install with PGXN]

===mysql_fdw===
This extension implements a Foreign Data Wrapper for MySQL. It is supported on PostgreSQL 9.1 and above.
* [http://github.com/dpage/mysql_fdw source code]
* [http://pgxn.org/dist/mysql_fdw/ install with PGXN]
* [http://blogs.enterprisedb.com/2011/08/01/postgresql-9-1-meet-mysql/ example]

===tds_fdw(not working)===
This project is not maintained anymore. Consider using odbc_fdw below to access Microsoft SQL Server and derived.
I guess you can meanwhile do the reverse, access Postgresql database within Microsoft SQL Server using Linked Servers.

===odbc_fdw===
A wrapper for databases with an ODBC driver, including Oracle, DB2, Microsoft SQL Server, Sybase, Pervasive SQL, IBM Lotus Domino, MySQL, PostgreSQL and desktop database products such as FileMaker and Microsoft Access:
* [https://github.com/ZhengYang/odbc_fdw source code]
* [http://pgxn.org/dist/odbc_fdw/ install with PGXN]
* [http://www.postgresonline.com/journal/archives/249-ODBC-Foreign-Data-wrapper-to-query-SQL-Server-on-Window---Part-2.html Using odbc_fdw on windows to query sql server (Postgres OnLine Journal March/April 2012)]

===jdbc_fdw===
A wrapper for databases with a JDBC driver.
* [https://github.com/atris/JDBC_FDW source code]

===informix_fdw (WIP)===
* [https://github.com/credativ/informix_fdw source code]

== NoSQL Databases Wrappers ==

===couchdb_fdw===
A wrapper for [http://couchdb.apache.org/ CouchDB]
* [https://github.com/ZhengYang/couchdb_fdw source code]
* [http://pgxn.org/dist/couchdb_fdw/ install with PGXN]

===mongo_fdw===
A wrapper for [http://www.mongodb.org/ MongoDB]
* [https://github.com/citusdata/mongo_fdw source code]
* [http://pgxn.org/dist/mongo_fdw/ install with PGXN]

===redis_fdw===
A wrapper for [http://redis.io/ Redis]
* [https://github.com/dpage/redis_fdw source code]
* [http://pgxn.org/dist/redis_fdw/ install with PGXN]

===Neo4j fdw===
A wrapper for Neo4j [http://www.neo4j.org/ Neo4j]
* [https://github.com/nuko-yokohama/neo4j_fdw source code]

== File Wrappers ==

===file_fdw===
A CSV files wrapper. Delivered as an official extension of PostgreSQL 9.1
* [http://www.postgresql.org/docs/9.1/static/file-fdw.html documentation]
* [http://www.depesz.com/index.php/2011/03/14/waiting-for-9-1-foreign-data-wrapper/ example]
* [http://www.postgresonline.com/journal/archives/250-File-FDW-Family-Part-1-file_fdw.html Another example] Postgres OnLine Journal May 2012

===file_text_array_fdw===
Another CSV wrapper
* [https://github.com/adunstan/file_text_array_fdw source code]
* [http://www.postgresonline.com/journal/archives/251-File-FDW-Family-Part-2-file_textarray_fdw-Foreign-Data-Wrapper.html How to use it] Postgres OnLine Journal May 2012

===file_fixed_length_record_fdw===
Fixed-width flat file wrapper
* [https://github.com/adunstan/file_fixed_length_record_fdw source code]

== Others ==

===twitter_fdw===
A wrapper fetching text messages from Twitter over the Internet and returning a table
* [https://github.com/umitanuki/twitter_fdw source code]
* [http://pgxn.org/dist/twitter_fdw/ install with PGXN]

===ldap_fdw===
Allows PostgreSQL to query an LDAP server and retrieve data from some pre-configured Organizational Unit
* [https://github.com/guedes/ldap_fdw source code]
* [http://pgxn.org/dist/ldap_fdw/ install with PGXN]

===PGStrom===

uses GPU devices to accelarate sequential scan on massive amount of records with complex qualifiers.
* http://wiki.postgresql.org/wiki/PGStrom

===s3_fdw===
Reads files located in Amazon S3
* [https://github.com/umitanuki/s3_fdw source code]
* [http://pgxn.org/dist/s3_fdw/ install with PGXN]

===www_fdw===
Allows to query different web services:
* [https://github.com/cyga/www_fdw/ source code]
* [https://github.com/cyga/www_fdw/wiki documentation/examples]
* [http://pgxn.org/dist/www_fdw/ install with PGXN]

=Multicorn Foreign Data Wrappers=

[http://multicorn.org/ Multicorn] is an extension that allows FDWs to be written in Python

== SQL Database Wrappers ==

===multicorn.sqlalchemyfdw===
This fdw can be used to access data stored in any database supported by the sqlalchemy python toolkit.
* [http://multicorn.org/foreign-data-wrappers/#sqlalchemy-foreign-data-wrapper documentation]

== File Wrappers ==

===muticorn.fsfdw===
This fdw can be used to access data stored in various files, in a filesystem. The files are looked up based on a pattern, and parts of the file's path are mapped to various columns, as well as the file's content itself.
* [http://multicorn.org/foreign-data-wrappers/#filesystem-foreign-data-wrapper documentation]

===multicorn.csvfdw===
This fdw can be used to access data stored in CSV files. Each column defined in the table will be mapped, in order, against columns in the CSV file.
* [http://multicorn.org/foreign-data-wrappers/#csv-foreign-data-wrapper documentation]

== Others ==

===multicorn.rssfdw===
This fdw can be used to access items from an rss feed.
* [http://multicorn.org/foreign-data-wrappers/#rss-foreign-data-wrapper documentation]

===multicorn.hivefdw===
Used to access Apache Hive tables.
* [https://github.com/youngwookim/hive-fdw-for-postgresql source code]
[[Category:Foreign-data wrapper|!]]

Pgcon2013unconference

2013-05-25T19:32:30Z

Dfetter: Minor edits #1

= pgCon 2013 Unconference Day =

The PostgreSQL Community is having our first Unconference Day at pgCon 2013 in Ottawa! This event, sponsored by Salesforce.com, extends pgCon and gives us additional opportunities to share, collaborate, and discuss about PostgreSQL development, hacking, usage, and community.

For more about unconference days and why we're doing this, see the [[pgConUnconferenceFAQ|Unconference Day FAQ]].

If you are interested in holding a session, or you want someone else to do a session on a particular topic on the Unconference day, please add your proposal to "session ideas" below.

== Basic Information ==

pgCon Unconference Day

Saturday, May 25th

10am to 5:30pm

Rooms: MNT202, MNT203, MRT256

== Unconference Schedule ==

{| 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"
|
|11:00AM
|12:00 Noon
|2:30PM
|3:30PM
|4:30PM
|-
| MNT202
| Future of Full Text Search - Dan Scott
| Connection Pooling Discussion - cbbrowne
| [[2013UnconfFutureOfJSON|Future of JSON]] - Andrew Dunstan
|
| Pluggable Storage API -- continued
|-
| MNT203
| [[2013UnconfPluggableStorage|Pluggable Storage Engine]] - Galy Lee
| [http://wiki.postgresql.org/wiki/Pgcon2013unconference#Future_of_FDW Future of FDW] - David Fetter
| OpenStreetMap + Postgis - Hartmut
| Replication Features Wishlist
| Spillover Slot
|-
| MRT256
| Discussion on pg_upgrade - B. Momjian
| [[2013UnconfFakingIt|Faking it - Synthesizing data for talks/tests]] - PVH
| PostgreSQL Lower Layer Tuning - Susanne Ebrecht
| Migration methods discussion - Daichi Egawa
| Spillover Slot
|-
| Back of MNT203
| Open Hack Session
| Open Hack Session
| Open Hack Session
| Open Hack Session
| Spillover Slot
|}

1pm to 2:30pm Lunch: PHP Discussion with Hartmut, [[PostgreSQL_testing_brainstorming:_PGCon2013_unconference_notes|Testing PostgreSQL]] with Mark Wilding

== How Sessions are Selected ==

No predetermined schedule is set for the Unconference Day beforehand. Instead, participants in the Unconference bring their ideas, demands, wishlists and discussion topics, and propose sessions at 10am in MNT 202. Anyone can lead a session. Sessions are accepted by acclaim, and scheduled collaboratively in the first period from 10am to 11am.

In order to get things started quickly on the Unconference Day, participants are encouraged to post session ideas on the wiki, below, before the unconference actually starts.

For more information, see the [[pgConUnconferenceFAQ|Unconference Day FAQ]]

== Session Ideas ==

If you wish to lead a session at the Unconference Day, or if you wish someone else would hold one on a specific topic, please propose it below. Copy this template and add your session proposal:

=== My Session Idea ===

Proposed By: Me

Session Type: Presentation/Round-table/Open Discussion/Hacking/Other

Description: write a few lines of description of your session idea here

Attendees: anyone who thinks they'll attend this, add your name here

=== PostgreSQL.org Testing Brainstorming ===

Proposed By: Josh Berkus

Session Type: Open Discussion

Description: the regression tests and the Buildfarm don't cover anywhere near all the kinds, or scope, of testing we want to do with Postgres, especially during the Beta Testing period. What other kinds of testing could we be doing? How can we increase test coverage? How can we get new contributors involved in testing?

*[[PostgreSQL_testing_brainstorming:_PGCon2013_unconference_notes|Notes]]

Attendees: put your name here:

* [[User:Hholzgra|Hartmut]]
* Nat Wyatt
* [[User:Dbs|Dan Scott]]

=== Enhancement of PostgreSQL testing framework ===

Proposed By: Galy Lee

Session Type: Presentation/Open Discussion

Description: We had enhanced three parts to current PostgreSQL regression test suite, those are: new replication testing framework, kernel testing framework for index/transaction/buffer page module, enhancement of isolation testing framework with synchronization mechanism. I will introduce our works and hope to discuss with the community how to make our testing framework better.

[https://wiki.postgresql.org/wiki/File:Pg_testframework.pptx slides]

Attendees:

* Galy
* [[User:Hholzgra|Hartmut]]

=== Connection Handles for SQL/MED Brainstorming ===

Proposed By: David Fetter

Session Type: Presentation/Open Discussion/Hacking

Description: Neither SQL/MED nor we provide a way to monitor or use the remote connection directly. We need to figure out how to fix this.

Attendees:

* David Fetter

* Me (Susanne)

* Bernd Helmle

=== Trigger-Based Replication Brainstorming ===

Proposed By: Christopher Browne

Session Type: Open Discussion

Description: What are people liking/not liking about Slony, Londiste, Bucardo? What features are not available that would be valuable to have? What backend features would be useful to make implementations better/faster/more reliable?

Attendees: cbbrowne, me (Susanne), Moshe Jacobson

=== Connection Pooling ===

Proposed By: Christopher Browne

Session Type: Open Discussion

Description: We have a bunch of connection pooling systems (pgpool, pgbouncer, ...); all are limited in usefulness because they do not support the diverse set of connection modifications supported by Postgres (e.g. - ssl authentication, LDAP, etc).

Java folk often implement poor home-grown solutions, but there exist maintained options (c3p0, dbcp).

Note that Other Vendors sometimes include options in their "core". What would we like/need?

Attendees: cbbrowne

==== Notes ====

Point of session: examine state of existing options

* PgBouncer:
** pooler, round robin, limited load balancing
** transparent to application, ease of use for disaster recovery, moving masters

* pgPool
** load balancer, pooler, round-robin
** can examine queries (read / write, direct appropriately to master/slave)
** tries to do everything, but slower and more complex?

* HA Proxy
** TCP load balancer, HA
** not Pg-specific

Issue: how to deal with multi-master scenarios (e.g. Postgres XC)

Idea: integrate pooling in libpq (e.g. PgBouncer, as BSD licence)
*Pros:
** ease of configuration
*Cons:
** lack of flexibIlity,
** not able to separate pooler from DB server(s)
** configuration and operation tied to DB server

Other possibilities:
* integrate pooling in language DB drivers

General consensus (''correct if wrong''):
* reason for plethora of solutions is plethora of different scenarios
* integrating pooling in PostgreSQL (libpq) not advantageous
* multi-master is a tricky problem

=== Open Hack Session ===

Proposed By: [[User:Qdw | Quinn Weaver]]

Session Type: Hacking

Description: Bring a project or come looking to join, work in a team or solo, use IRC and sneakernet to help each other out — just hack!

#pgcon_hack on freenode

Attendees:

* [[User:Qdw | Quinn]]
* Satoshi
* [[User:Hholzgra|Hartmut]]

==== Planned projects ====

* Quinn: I will be giving [https://github.com/qdw/pg-version-compare pg-version-compare] some much-needed love (top priority: adding data for recent PostgreSQL releases).
* Satoshi: I will be hacking [https://github.com/uptimejp/pgperf-snapshot pgperf-snapshot] to catch up to the 9.3 (and add some unit tests). See [http://www.uptime.jp/pgperf-snapshot/docs_en/ docs] for more details.
[[Category:PostgreSQL Events]]

==== proposed bite-size projects ====
* url datatype (with functions for: username, password, hostname, path, protocol?)
* email datatype (with functions for username, hostname?)
* an interesting sample database showing many postgres features (in various sizes)
* suffix datatype (ask Dim)
* pg_graph - ascii art graphing extension for PSQL users
* "SHOW ..." alternatives to psql \... commands? As a mostly MySQL user i'm especially confused by the lack of a "SHOW CREATE TABLE ..." [[User:Hholzgra|Hholzgra]] 20:07, 24 May 2013 (UTC)

=== The Future of Postgres ===

Proposed by: Josh Berkus

Session Type: Open discussion

Description: where do you think PostgreSQL should go in 2 years? 5? 10? What features do you see as essential to Postgres continuing to thrive? Who's going to work on them?

=== Lower Level Tuning ===

Proposed By: Susanne Ebrecht

Session Type: Presentation and Open Discussion

Description: Databases are real I/O and RAM eater. The talk gives an overview what administrators need to consider on buying new hardware, what they need to tune on Linux level and which variables they might want to change in postgresql.conf to get better performance.

Attendees: Moshe Jacobson

=== Why VACUUM? ===

Proposed By: Susanne Ebrecht

Session Type: Presentation and Open Discussion

Description: For what does PostgreSQL need VACUUM? Why should it run? When is autovacuum triggered? Why autovacuum not alwys works ...

Attendees: anyone who thinks they'll attend this, add your name here

=== InnoDB - purge_thread instead of VACUUM ===

Proposed By: [[Hartmut Holzgraefe]]

Session Type: Presentation and Open Discussion

Description: PostgreSQL and InnoDB/XtraDB are both implementing MVCC in similar ways, differ at the detail level though. One of the differences is how to get rid of MVCC records that are no longer needed ... where PostgreSQL requires explicit VACUUM operation (or semi-implicit AUTOVACUUM) the InnoDB storage engine uses one or (in recent releases) more background threads to get rid of old MVCC entries (almost) completely transparantly ... I'd like to have a look at the implementation details and the advantages and disadvantages of both approaches ...

Attendees: anyone who thinks they'll attend this, add your name here

=== What more is needed for better JSON use? ===

Proposed By: Andrew Dunstan

Session Type: Open Discussion

Description: Now we have a lot of enhanced JSON functionality in 9.3, what more is needed for more effective and useful JSON?

Attendees: add your name here

=== Don't be afraid to give a talk on PGCon ===

Proposed By: Susanne Ebrecht

Session Type: Open Discussion

Description: How to prepare a good talk, ...

Attendees: Moshe Jacobson

=== Speaker wanted! Upgrading a running HA system without downtime and without lost of HA ===

Proposed By: Susanne Ebrecht

Description: Hot upgrading to a new release by always minimum have running one master and minimum one slave .....

Attendees: add your name here

=== The Future of Full Text Search ===

Proposed by: [[User:Dbs|Dan Scott]]

Description: Full text search in PostgreSQL is already pretty awesome, but there may be a number of ways we can enhance it to provide a more competitive alternative to Solr, Elastic Search, Sphinx, and other dedicated full text search engines. Let's figure out what we are already working on and where the low-hanging fruit may be for further enhancements in PostgreSQL 9.4 and beyond, in areas like performance, flexibility (contrib examples of alternate parsers and ranking algorithms? parsers/dictionaries implemented in Python or Perl?), new operators, more language support, ...

'''Attendees''' (''hopefully''):

* Alexander Korotkov
* Oleg Bartunov
* Teodor Sigaev

'''Attendees''' (''firm''):

* Dan Scott
* [[User:3manuek|Emanuel Calvo]]
* and you if you're interested... add yourself to the list!

=== Postgres-XC documentation review and status ===

Proposed by: [[User:3manuek|Emanuel Calvo]]

Session Type: Open discussion

Description: Actually the documentation has some lack of details (i.e. How to add more coordinators? Which steps should I do after that? What if I need to reduce data nodes? Where do I need to create the users (actually we know we need to create them on the coordinators, but is not explicitly on the doc)? )

Attendees:

* [[User:Hholzgra|Hartmut]]

=== PHP::mysqlnd features for ext/pgsql? ===

Proposed By: [[Hartmut Holzgraefe]]

Session Type: Presentation/Open Discussion

Description: The three MySQL extenions in PHP (mysql, mysqli, PDO driver) now can use the bundled mysqlnd library instead of the standard libmysqlclient C API. This allows for less copying in memory and better memory use tracking, and at the same time several plugin points have been added that allow for the addition of custom loadbalancing/read-write-splitting, query cache and others at the PHP engine level, transparent to the actual PHP application on top. This talk is going to describe the implementation in a bit more detail, then turning into an open discussion whether a similar reimplementation of the PostgreSQL client communication code to replace libpq would be feasible for ext/pgsql and the PostgreSQL PDO driver ...

Attendees: anyone who thinks they'll attend this, add your name here

=== "Something about OpenStreetMap" ===

Proposed By: [[Hartmut Holzgraefe]]

Session Type: Presentation/Open Discussion/

Description: This could cover any of:

* General User perspective
** what is OpenStreetMap to begin with?
** how to contribute map data?

* Database perspective
** how is the master database organized?
** how to import full planet data or local regional data into PostGIS?

* Toolchain perspective
** how to go from PostGIS (or other forms of OSM data) to rendered maps?
** how to create interactive web maps with OpenLayers or LeafNode?

=== Pluggable Storage Engine ===

Proposed By: Galy

Session Type:Open Discussion

Description:

As Josh had mentioned

'we have a number of people who would like to do something interesting and substantially different with PostgreSQL storage, and will likely be forced to fork PostgreSQL to get their ideas to work. Index-organized tables, fractal trees, JSON trees, EAV-optimized storage, non-MVCC tables, column stores, hash-distributed tables and graphs all require changes to storage which can't currently be fit into the model of index classes and blobs we offer for extensibility of data storage. Transactional RAM and Persistent RAM in the future may urge other incompatible storage changes.

As a community, we want to capture these innovations and make them part of mainstream Postgres, and their users part of the PostgreSQL community. The only way to do this is to have some form of pluggable storage, just like we have pluggable function languages and pluggable index types.'

It will be interesting to discuss how we can achieve this.

Attendees: anyone who thinks they'll attend this, add your name here:

* Tom Lane
* Koichi
* Nat Wyatt
* Subho Chatterjee

=== Migration methods Disscussion ===
Proposed By: Daichi Egawa

Session Type: Presentation and Open Discussion

Description:

Migration to PostgreSQL is hot today. I will mainly talk about application porting(convert of SQL). There are various ways, methods and tools. So, I would like to discuss about their each merits.If there is enough time, I will also talk about migration of data.

Attendees: anyone who thinks they'll attend this, add your name here

=== Future of FDW ===

Proposed by : David Fetter

Sesstion Type: Open Discussion

Description:

Minutes:

* Connections alive/dead. Shutdown connections for the FDW.
* One connection handle per user/server pair.
* Planning queries across the nodes. Maybe specifying connection properties (latency? amount of rows). AlTER SERVER. Daemon updating the properties?
* Knowledge about other nodes as Postgres-XC. Is something different but we were discussing how it can work.
* Triggers on Foreign tables (insert, delete, truncate?)
* functions on foreign queries (execute locally? execute on the foreign host? mapping?)
* Data protection of data being pushing by the query to the foreign host? Error handling and errors prompted by the foreign host.
* Parallel searching across several Foreign connections? Somebody suggest to use some node execution as the aggregation's. Map reduce technique.
* Two-phase commit for durability on writing queries using FDW.

TODO:

Pgcon2013unconference

2013-05-24T16:32:05Z

Dfetter: /* Connection Handles for SQL/MED Brainstorming */

Pgcon2013unconference

2013-05-24T15:45:19Z

Dfetter: Added Connection Handles for SQL/MED session

IRC2RWNames

2013-04-23T17:02:11Z

Dfetter: /* List of IRC nicks with their respective real world names */

=== List of IRC nicks with their respective real world names ===

You can find many PostgreSQL users and developers chatting in [irc://irc.freenode.net/postgresql #postgresql on freenode]. Here's more information about some of the regulars there. '''Note:''' people are on the list below only when they want to be. Do not (re-)add anyone without their express permission.

{| border="1"
|-
!Nickname || Real Name
|-
|ads || Andreas Scherbaum
|-
|agliodbs, aglio2 (freenode), jberkus (oftc) || Josh Berkus
|-
|ahammond || Andrew Hammond
|-
|alvherre || Alvaro Herrera
|-
|andres || Andres Freund
|-
|Assid || Satish Alwani
|-
|aurynn || Aurynn Shaw
|-
|BlueAidan/BlueAidan_work || [[user:davidblewett | David Blewett]]
|-
|bmomjian || Bruce Momjian
|-
|cbbrowne || Christopher Browne
|-
|cce || Clark C. Evans
|-
|chicagoben || Benjamin Johnson
|-
|crab || Abhijit Menon-Sen
|-
|Crad || Gavin M. Roy
|-
|daamien || Damien Clochard
|-
|DarcyB || Darcy Buskermolen
|-
|darkixion || Thom Brown
|-
|davidfetter || David Fetter
|-
|dbb || Brian Hamlin / darkblue_b
|-
|dcolish || [http://www.unencrypted.org Dan Colish]
|-
|dcramer || Dave Cramer
|-
|DeciBull, TheCougar || Jim C. Nasby
|-
|dennisb || Dennis Björklund
|-
|depesz || Hubert Lubaczewski
|-
|devrimgunduz || Devrim Gündüz
|-
|digicon || [http://digicondev.blogspot.com Zach Conrad]
|-
|dim || Dimitri Fontaine
|-
|direvus || Brendan Jurd
|-
|drbair || Ryan Bair
|-
|DrLou || Lou Picciano
|-
|duck_tape || Adi Alurkar
|-
|dvl || [http://langille.org/ Dan Langille]
|-
|eggyknap || Joshua Tolley
|-
|endpoint_david || David Christensen
|-
|eulerto || Euler Taveira
|-
|f3ew/devdas || Devdas Vasu Bhagat
|-
|feivel || Michael Meskes
|-
|elein || Elein Mustain
|-
|gleu || Guillaume Lelarge
|-
|gorthx || [[User:Gabrielle|Gabrielle Roth]]
|-
|grzm || Michael Glaesemann
|-
|gsmet || Guillaume Smet
|-
|gregs1104 || Greg Smith
|-
|gurjeet || [[User:singh.gurjeet|Gurjeet Singh]]
|-
|G_SabinoMullane || Greg Sabino Mullane
|-
|HarrisonF || Harrison Fisk
|-
|ioguix || Jehan-Guillaume de Rorthais
|-
|indigo || Phil Frost
|-
|intgr || Marti Raudsepp
|-
|JanniCash || Jan Wieck
|-
|jconway || Joe Conway
|-
|jdavis, jdavis_ || Jeff Davis
|-
|jkatz05 || Jonathan S. Katz
|-
|johto || Marko Tiikkaja
|-
|jurka || Kris Jurka
|-
|justatheory || David Wheeler
|-
|jpa || Jean-Paul Argudo
|-
|jwp || James Pye
|-
|j_williams || Josh Williams
|-
|kgrittn || Kevin Grittner
|-
|klando || [[User:c2main|Cédric Villemain]]
|-
|larryrtx || Larry Rosenman
|-
|linuxpoet, postgresman || Joshua D. Drake
|-
|lluad || Steve Atkins
|-
|lsmith || Lukas Smith
|-
|magnush || Magnus Hagander
|-
|marco44 || Marc Cousin
|-
|markwkm || Mark Wong
|-
|mastermind || [[user:mastermind | Stefan Kaltenbrunner]]
|-
|mbalmer || [[user:mbalmer | Marc Balmer]]
|-
|merlin83 || Chua Khee Chin
|-
|merlinm || Merlin Moncure
|-
|metatrontech || Chris Travers
|-
|miracee || Susanne Ebrecht
|-
|Moosbert || Peter Eisentraut
|-
|neilc || Neil Conway
|-
|oicu || Andrew Dunstan
|-
|okbobcz || Pavel Stehule
|-
|pg_docbot || [[IRCBotSyntax]]
|-
|pgSnake || Dave Page
|-
|PJMODOS || Petr Jelínek
|-
|Possible || Robert Ivens
|-
|postwait || Theo Schlossnagle
|-
|prothid || R Brenton Strickler
|-
|psoo || Bernd Helmle
|-
|PSUdaemon || Phil Sorber
|-
|pyarra || Philip Yarra
|-
|raptelan || [[user:Cshobe|Casey Allen Shobe]]
|-
|rhaas || Robert Haas
|-
|RhodiumToad (formerly AndrewSN) || Andrew Gierth
|-
|Robe || [[user:Robe | Michael Renner]]
|-
|rotellaro || Federico Campoli
|-
|rz || Kirill Simonov
|-
|SAS || Stéphane Schildknecht
|-
|schmiddy || Josh Kupershmidt
|-
|scrappy || Marc G. Fournier
|-
|selenamarie || Selena Deckelmann
|-
|SkippyDigits || Sherri Kalm
|-
|Snow-Man || Stephen Frost
|-
|Spritz || Matteo Beccati
|-
|sternocera || Peter Geoghegan
|-
|StuckMojo, MojoWork || Jon Erdman
|-
|swm || Gavin Sherry
|-
|vy || Volkan YAZICI
|-
|wulczer || Jan Urbański
|-
|xaprb || Baron Schwartz
|-
|xzilla, xzi11a || [[User:Xzilla|Robert Treat]]
|}

[[Category:Community]]

PGDay NYC 2013 Talks

2013-03-26T05:04:02Z

Dfetter: /* Added my slides */

= PGDay NYC 2013 Talks =

== Friday March 22nd, 2013 ==

=== Liberty Hall C ===

* [http://www.slideshare.net/davidfetter/ct-es-pastpresentfuturenycpgday20130322 CTEs: Past, Present and Future (David Fetter)]
* [http://momjian.us/main/writings/pgsql/locking.pdf Understanding the Postgres Lock Manager (Bruce Momjian)]
* [http://plv8-talk.herokuapp.com/ Embracing the Web with JSON and PLV8 (Will Leinweber)]
* [https://speakerdeck.com/mbryzek/schema-evolutions-at-gilt-groupe Schema Evolutions at Gilt Groupe (Michael Bryzek)]

=== Liberty Hall A ===

* [[:File:PPCD.pdf|Postgres Plus Cloud Database (Dave Page)]]
* [https://github.com/petere/logging-hooks-presentation Toward real-time log analysis (Peter Eisentraut)]

[[Category:PostgreSQL Events]]

Working with Git

2013-01-25T04:27:24Z

Dfetter: /* Getting Started */

This page collects various wisdom on working with the [http://git.postgresql.org/ PostgreSQL Git repository]. There are also [[Other Git Repositories]] you might work with, most notably the official [http://github.com/postgres Github mirror] which you might fork on that site.

==Getting Started==

A simple way to get started might look like this:

git clone git://git.postgresql.org/git/postgresql.git
cd postgresql
git checkout -b my-cool-feature
$EDITOR
git commit -a
git diff master my-cool-feature | filterdiff --format=context > ../my-cool-feature.patch

Note that <code>git checkout -b my-cool-feature</code> creates a new branch and checks it out at the same time. Typically, you would develop each feature in a separate branch.

See the documentation and tutorials at http://git.or.cz/ for a more detailed Git introduction. For a more detailed lesson, check out http://progit.org and maybe get a hardcopy to help support the site.

You may wish to put the following in your .git/info/exclude [[GitExclude]].
Now that the master repository has been converted to git, the standard
.gitignore files should cover all build products, so you don't need
most of what is listed in that reference. You might still want to
exclude *~, tags, and /cscope.out, though.

PostgreSQL developers have traditionally preferred context diffs (<code>diff -c</code>) over unified diffs (<code>diff -u</code>). At least some major committers who you will probably have to run your patch by heavily prefer context diffs. Bizarrely, Git doesn't easily produce context diffs. So there is some need for fiddling around, either using the <code>filterdiff</code> utility as above (from the [http://freshmeat.net/projects/patchutils/ patchutils] distribution) or using the method described in [[#Context diffs with Git|Context diffs with Git]] below.

=== Keeping your master branch local synchronized ===

First, add the origin as a remote. You only need to do this once:

git remote add origin git://git.postgresql.org/git/postgresql.git

Next, fetch from your public git repository:

git fetch origin master

Merge any new patches from your public repository:

git merge FETCH_HEAD

Merge in any changes from the main branch:

git fetch origin master
git merge FETCH_HEAD

Now check that it still compiles, passes regression, etc. Make sure you've
invoked ./configure, and then:

make check
make maintainer-clean

Assuming all that's good, do a dry run.

git push --dry-run origin master

If that's happy, push it out to your public repository.

git push origin master

If not, fix any merge failures, do an other dry run, and push.

=== Tracking Other Branches ===

Lets say you're happy tracking master, but you'd really like to track any one of the other potential branches at git.postgresql.org

git remote add <super-fun-branch> git://git.postgresql.org/super-fun-branch.git
git fetch super-fun-branch
git checkout super-fun-branch #this will stage your remote branch for a local checkout
git checkout -b super-fun-branch-name #the name can be wahtever you choose

Now you have a local branch within your local git repo tracking a different branches history. Most importantly, you can now push to that repo if you have to without making an explicit clone to track the history. It's pretty much impossible to not share some common history with the master branch.

=== Using Back Branches ===

Since the git repository contains branches for each of the major versions of PostgreSQL, it's easy to work on the latest code from an older version instead of the current one. Here's how you might list the possibilities and checkout an older version:

git branch -r
git checkout -b REL8_3_STABLE origin/REL8_3_STABLE

Note that if you've already checked out and used a later version, you might need to clean up some of the files left behind by it. It's suggested to run:

make maintainer-clean

To get rid of as many of those as possible. You might need to delete some files left behind after that anyway before git will allow you to do the checkout (src/interfaces/ecpg/preproc/preproc.y can be a problem with the specific example above).

=== Testing a patch ===

This is a typical setup to review a patch text file, as typically sent by e-mail:

git checkout -b feature-to-review
patch -p1 < feature.patch

If the patch fails to apply, there will be file.rej files left behind showing the part that didn't apply. If your directory tree is clean of build information, you can easily find these later using:

git status

=== Context diffs with Git ===

Copy [http://git.postgresql.org/gitweb?p=postgresql.git;a=blob_plain;f=src/tools/git-external-diff;hb=HEAD git-external-diff] into libexec/git-core/ of your git installation and configure git to use that wrapper with:

git config [--global] diff.external git-external-diff

''--global'' makes the configuration global for your user - otherwise it is just configured for the current repository.

For every command which displays diffs in some way you can use the parameter "--[no-]-ext-diff" to enable respectively disable using the external diff command.

For the ''git diff'' command ''--ext-diff'' is enabled by default - for any other command like ''git log -p'' or ''git format-patch'' it is not!

This method should work on all platforms supported by git.

If you don't want to configure the external wrapper permanently or you want to overwrite it you can also git like:

export GIT_EXTERNAL_DIFF=git-external-diff
git diff --[no-]ext-diff

==== Options to diff ====
When using the above wrapper you can override the options for '''diff''' by specifying the environment variable '''DIFF_OPTS''' - it defaults to ''-pcd''.
Also, postgres uses 4 column tab spacing (see also [http://developer.postgresql.org/pgdocs/postgres/source-format.html]).

export DIFF_OPTS=-pcd
export LESS=-x4

==== Patch cleanup ====

Patch diff submission works best when the author does a round of self-review of the actual patch--not just the code, but the physical diff file produced. [[Creating Clean Patches]] covers practices commonly used to produce better patch diff output.

==Publishing Your Work==

If you develop a feature over a longer period of time, you want to allow for intermediate review. The traditional approach to that has been emailing huge patches around. The more advanced approach that we want to try (see also Peter Eisentraut's [http://petereisentraut.blogspot.com/2008/02/on-patch-review.html blog entry]) is that you push your Git branches to a private area on <code>git.postgresql.org</code>, where others can pull your work, operate on it using the familiar Git tools, and perhaps even send you improvements as Git-formatted patches. See [http://git.postgresql.org/adm/help the git.postgresql.org site] for instructions on how to sign up, and how to use the repository. You may need to eventually create a patch via e-mail as part of officially [[Submitting a Patch]].

==Pushing New Branches==

If you create a new branch, generally for a new feature test, you'll need to push it to git.postgresql.org.

git push origin new_feature_branch

Note that, if you have a completely blank repository (such as a new repo for a pgfoundry project) then not even the branch "master" will exist and will need to be pushed.

If you ''are'' working with the postgresql core code, do NOT casually make up your own branches and push them, without clearing it on the pgsql-hackers list first. Generally, you want to use your private repo area instead.

==Removing a Branch==

Once your feature has been committed to the PostgreSQL repository, you can usually remove your local feature branch. This works as follows:

# switch to a different branch
git checkout master
git branch -D my-cool-feature

==Working with the users/foo/postgres.git==

One option while requesting a project at git.postgresql.org is to have a clone of the main postgresql repository.

That is very nice feature, but how do you sync the upstream code?!

One method is to create a git clone in your own repository and add a new remote to handle the syncing :

# clone your repos
git clone ssh://git@git.postgresql.org/users/foo/postgres.git my_postgres

# add a new remote
git remote add pgmaster git://git.postgresql.org/git/postgresql.git

# track some old versions
git checkout -b REL8_3_STABLE origin/REL8_3_STABLE
git checkout -b REL8_4_STABLE origin/REL8_4_STABLE

# change the remote of master and our old versions tracked
git config branch.REL8_3_STABLE.remote pgmaster
git config branch.REL8_4_STABLE.remote pgmaster
git config branch.master.remote pgmaster

# pull from postgres official git for each branch
# and finally push to origin
git checkout master
git pull
git push origin
git checkout REL8_3_STABLE
git pull
git push origin
git checkout REL8_4_STABLE
git pull
git push origin

This way, PostgreSQL is easy to sync for each branch. Pulling from the official and pushing to your own repository.

Create your own branch and work as usual. Users who have a local clone of the postgresql.git can add your branch in their repository and happily merge, just as you do.

==Using the Web Interface==

Try the web interface at http://git.postgresql.org/. It offers browsing, "blame" functionality, snapshots, and other advanced features, and it is much faster than CVSweb. Even if you don't care for Git or version control systems, you will probably enjoy the web interface.

==RSS Feeds==

The Git service provides RSS feeds that report about commits to the repositories. Some people may find this to be an alternative to subscribing to the pgsql-committers mailing list. The URL for the RSS feed from the PostgreSQL repository is http://git.postgresql.org/?p=postgresql.git;a=rss. Other options are available; they can be found via the [http://git.postgresql.org/ home page] of the web interface.

==PostgreSQL Style==

The PostgreSQL source uses 4-character tabs, making the output from <code>git diff</code> look odd. You can fix that by putting this into your.<code>git/config</code> file:

[core]
pager = less -x4

==Continuing the "rsync the CVSROOT" workflow==

Aidan van Dyk {{messageLink|20090602162347.GF23972@yugib.highrise.ca|published a nice tutorial}} on how to keep several branches using a single copy of historical objects. This is roughly equivalent to keeping several checkouts of a rsync'ed copy of CVSROOT, which is what some committers were used to doing with CVS.

[[Category:Git]]

PostgreSQL Conference Europe Talks 2012

2012-10-25T10:21:11Z

Dfetter: /* Oops! Fixed presentation date. */

= PostgreSQL Conference Europe 2012 Talks =

== Talks: Wednesday 24th October, 2012 ==

=== Bellevue ===

=== Seine ===

=== Thames ===

* [[Media:Pgconfeu12-collectd%2Bpsql.pdf|Watch your Elephants -- Using collectd for PostgreSQL performance analysis]] ([http://tokkee.org/ Sebastian 'tokkee' Harl])
* [[Media:Range-types.pdf|Range Types in PostgreSQL 9.2 - Your Life Will Never Be the Same (Jonathan S. Katz)]]

=== Vlatva ===

== Talks: Thursday 25th October, 2012 ==

=== Bellevue ===

=== Seine ===

=== Thames ===

* [[Media:Universal_Data_Access_with_SQL_MED.pdf|Universal Data Access with SQL/MED (David Fetter)]]

=== Vlatva ===

[[Category:PostgreSQL Europe]]

PostgreSQL Conference Europe Talks 2012

2012-10-25T10:15:34Z

Dfetter: /* Thames */

= PostgreSQL Conference Europe 2012 Talks =

== Talks: Wednesday 24th October, 2012 ==

=== Bellevue ===

=== Seine ===

=== Thames ===

* [[Media:Pgconfeu12-collectd%2Bpsql.pdf|Watch your Elephants -- Using collectd for PostgreSQL performance analysis]] ([http://tokkee.org/ Sebastian 'tokkee' Harl])
* [[Media:Range-types.pdf|Range Types in PostgreSQL 9.2 - Your Life Will Never Be the Same (Jonathan S. Katz)]]
* [[Media:Universal_Data_Access_with_SQL_MED.pdf|Universal Data Access with SQL/MED (David Fetter)]]

=== Vlatva ===

[[Category:PostgreSQL Europe]]

PostgreSQL Conference Europe Talks 2012

2012-10-25T10:12:07Z

Dfetter: /* Added Universal Data Access with SQL/MED */

= PostgreSQL Conference Europe 2012 Talks =

== Talks: Wednesday 24th October, 2012 ==

=== Bellevue ===

=== Seine ===

=== Thames ===

* [https://wiki.postgresql.org/images/b/bc/Pgconfeu12-collectd%2Bpsql.pdf Watch your Elephants -- Using collectd for PostgreSQL performance analysis] ([http://tokkee.org/ Sebastian 'tokkee' Harl])
* [https://wiki.postgresql.org/images/f/f0/Range-types.pdf Range Types in PostgreSQL 9.2 - Your Life Will Never Be the Same (Jonathan S. Katz)]
* [[Media:Universal_Data_Access_with_SQL_MED.pdf|Universal Data Access with SQL/MED (David Fetter)]]

=== Vlatva ===

[[Category:PostgreSQL Europe]]

File:Universal Data Access with SQL MED.pdf

2012-10-25T10:08:18Z

Dfetter:

Shared Storage

2012-09-25T16:03:37Z

Dfetter:

One way to make a highly-available PostgreSQL pair is to use shared storage: a single, highly redundant disk array (usually an expensive SAN) that is connected to two servers. This topic is addressed briefly at both http://www.postgresql.org/about/press/faq and http://www.enterprisedb.com/products/allfaq.do

It's straighforward to build a shared storage implementation using PostgreSQL and either one of the proprietary clustering systems or using Linux-HA. And until PostgreSQL gets fully synchronous replication, it's a viable alternate solution for "must not lose a transaction" deployments when the storage used is much more reliable than the nodes.

The main things you have to figure out are a) which of the clustering software solutions you're going to use, ranging from the free Linux on to the multiple proprietary options, and b) how you're going to enforce a node that's been demoted from being the master from reconnecting again (what's called fencing). There's some overlap between those two decisions; not every cluster program supports every node fencing method.

Clustering software appropriate for this approach includes products from Veritas, Sun, RedHat, and the Linux HA project. Sun even mentions PostgreSQL support as a specific strength of their product at http://blogs.sun.com/SC/entry/migrating_from_veritas_cluster_server

One hard part is getting a heartbeat between the two servers sharing the SAN that is both sensitive enough to catch failures while not being so paranoid that it fails over needlessly (say, when load spikes on the primary and it slows down). Make sure you test that part out very carefully with any vendor you evaluate.

As far as the PostgreSQL specifics go, you need a solid way to ensure you've disconnected the now defunct master from the SAN (the classic "shoot the other node in the head" problem). All you *should* have to do is start the database again on the backup after doing that. That will come up as a standard crash, run through WAL replay crash recovery, and the result should be no different than had you restarted after a crash on the original node. The thing you cannot let happen is allowing the original master to continue writing to the shared SAN volume once that transition has happened.

The hard part of shared storage failover is always solving the "shoot the other node in the head problem", to keep a down node from coming back once it's no longer the active one. In order to do that well, you really need to lock the now unavailable node from accessing the storage at the hardware level--"fencing"--with disabling its storage port being one way to handle that. Figure out how you're going to do that reliably in a way that's integrated into a proper cluster manager, and there's no reason you can't do this with PostgreSQL.

There's a description of the fencing options for Linux-HA at http://www.clusterlabs.org/doc/crm_fencing.html The cheap way to solve this problem is to have a UPS that disables the power going to the shot node. Once that's done, you can then safely failover the shared storage to another system. At that point, you can probably even turn back on the power, presuming that the now rebooted system will be able to regain access to the storage during a fresh system start.

== Typical Setup ==

Here's one user (John Pierce) writing about this style of deployment:

In most of the HA clusters I've seen, the RAID controllers are in the SAN, not in the hosts, and they have their own failover, with shared write cache, also extensive use of ECC so things like double-bit memory errors are detected and treated as a failure. The sorts of high end SANs used in these kinds of systems have 5-9's reliability, through extensive use of redundancy, dual port disks, fully redundant everything, mirrored caches, etc.

Ditto, the servers used in these sorts of clusters have ECC memory, so memory failure should be detected rather than passed on blindly in the form of corrupted data. Server grade CPUs, especially the RISC ones, have extensive ECC internally on their caches, data busses, etc, so any failure there is detected rather than allowed to corrupt data. Failure modes can include things like failing fans (which will be detected, resulting in a server shutdown if too many fail), power supply failure (redundant PSUs, but I've seen the power combining circuitry fail). Any of these sorts of failures will result in a failover without corrupting the data.

And of course, intentional planned failovers to do OS maintenance... you patch the standby system, fail over to it and verify its good, then patch the other system.

We had a large HA system at an overseas site fail over once due to flooding in the primary computer room caused by a sprinkler system failure upstairs. The SAN was mirrored to a SAN in the 2nd DC (fiber inteconnected) and the backup server was also in the second DC across campus, so it all failed over gracefully. This particular system was large Sun hardware and big EMC storage, and it was running Oracle rather than Postgres. We've had several big UPS failures at various sites, too, ditto HVAC, over a 15 year period.

In my dev-lab tests of some clusters, I used the QLogic 5600 FC switch that connects my motly collection of servers... I used RHCS for one test, it supported the qlogic via telnet... I created two zone sets in the qlogic, one for each state, with the standby host blocked from accessing the LUN, and the cluster manager used telnet to talk to the switch. I ran heartbeats over two separate ethernets (one was the lab LAN segment, the other was a private switch i have all the servers connected to for various tests, and such). The qlogic switch also had another zoneset for all sorts of other servers and storage which wasn't affected by these clustering tests.

I don't like power cycling servers, so I'd prefer not to use power switch based fencing, although I believe my blade box's management unit is supported as a power fencing device.

== Credits ==

Past discussions of ways to do this on the PostgreSQL list include:
* http://markmail.org/message/s4gka6dotadefgll
* http://markmail.org/message/f7gsispb2e56d7k6
* http://markmail.org/message/hpjh4f4z7pxslmpf

And several pieces of good advice there have not yet been absorbed into this discussion.

Initial text here came from those discussions on the pgsql-general and pgsql-admin lists, primarily from Greg Smith and John Pierce.

[[Category:Clustering]]

TPC-H

2012-09-25T16:02:44Z

Dfetter:

The [http://www.tpc.org/tpch/ TPC-H Benchmark] is a popular one for comparing database vendors. It's possible to run the TPC-H data set on PostgreSQL without having a formal testing kit (although there is [[DBT-3]], a work in progress to provide a full kit). The results have generally been disappointing, for reasons that aren't necessarily relevant in the real world. PostgreSQL is missing some of the things needed to do well on this benchmark, whereas proprietary database vendors are so focused on it they will "game" TPC-H runs (add optimizations specifically aimed at it) to make absolutely sure they do well.

Notes:
* [http://dsl.serc.iisc.ernet.in/projects/PICASSO/picasso_download/doc/Installation/tpch.htm TPC-H data generation and loading]
* [http://monetdb.cwi.nl/SQL/Benchmark/TPCH/ TPC-H Performance Study] using an old version of PostgreSQL
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg01867.php Discussion of limitations] started by the above
* [http://m.tholis.webnode.com/news/tpc-h-fun-with-greenplum-single-node-edition-/ TPC-H fun with Greenplum (single node edition)] - leads into the below and discusses what's needed to do well on TPC-H
* [http://community.greenplum.com/showthread.php?t=113 GP SNE versus Postgres 8.4.2 - 22 Query Benchmark Results] (similar to TPC-H queries, tweaked to run better)
[[Category:Benchmarking]]

Planet PostgreSQL

2012-09-25T15:48:44Z

Dfetter: /* Are commercial posts allowed? */

[http://planet.postgresql.org/ Planet PostgreSQL] is a blog aggregation service run by the PostgreSQL community. In addition to the main Planet site, entries are published ("syndicated") to the [http://www.postgresql.org/ postgresql.org] site as well.

== Planet PostgreSQL Policy ==

The following simple rules cover the blogs being listed on Planet PostgreSQL:

* All blogs should be about PostgreSQL or closely related technologies. If you want to blog about other things as well, please put your PostgreSQL specific posts in a separate category/tag/label, and use the feed for this category only for Planet PostgreSQL.
* All topics related to PostgreSQL are of course appreciated - both technical and non-technical.
* All posts should be in English. If you want to blog in other languages, please put your PostgreSQL specific posts in a separate category/tag/label, and use the feed for this category only for Planet PostgreSQL.
* All blogs should be identified by the posters name. A nickname is allowed to be used in combination with this, but blogs without names are not allowed.
* Avoid inflammatory comments in syndicated posts. Personal attacks are not permitted.
* Publishing of advertising in the syndicated part of your blog is not permitted

Violating these rules will cause your blog to be removed from Planet PostgreSQL.

== Planet PostgreSQL FAQ ==

=== How can I remove a bad entry from the feed? ===

It's possible to login to the administration interface and hide an individual entry. If you realize you've made a mistake and done something like accidentally posting incorrectly tagged content, removing it on your own is recommended.

=== What are the right URLs to use for a labeled feed from [http://www.blogger.com blogger.com]? ===

Assuming your blog is named "blogname" and you've tagged a subset of your posts with the "postgresql" label, the correct URLs to input to the Planet code are:

* Feedurl: http://blogname.blogspot.com/search/label/postgresql
* Blogurl: http://blogname.blogspot.com/feeds/posts/default/-/postgresql

You can confirm those URLs display a suitable copy of your feed via a web browser before submitting them.

=== Are commercial posts allowed? ===

Informative entries that mention proprietary products are normally permissible, as long as the main entry is relevant to the PostgreSQL community. But the policy specifically prohibits publication of advertising in the portion of a blog that is syndicated to the Planet feed. It's recommended that blogs that may contain ads tag them appropriately, to provide a feed to the Planet without those entries included.

=== What constitutes an advertisement? ===

The primary test here is whether the information provided would be of some use even to people who have no interest in the commercial product mentioned. Consider what your entry would look like if all references to the product were removed. If there's no useful PostgreSQL content left after doing that, that post is an ad.

You can find a blog entry giving a more detailed opinion from one of the moderators about this subject at [http://blog.2ndquadrant.com/en/2011/06/planetary-alignment.html Planetary alignment]. That commentary is not part of the official policy.

=== What happens to blogs that violate the site policies? ===

A first violation of the advertising policy will result in the blog entry with the ad being removed, and a warning e-mail sent to the listed owner of the blog.

A second violation will resulting in the blog being removed from the Planet PostgreSQL feed. After a two month suspension period, the blog owner can submit their blog address--or a new feed URL better tagged to filter out advertisements--for reconsideration.

A third violation in any year will result in a full 12 month suspension of the blog from Planet PostgreSQL.

=== Who makes the moderation decisions about the Planet content allowed? ===

Site maintenance and moderation duty is done by a small team of volunteer moderators, primarily made up of [http://www.postgresql.org/community/contributors/ PostgreSQL contributors] from various companies who are familiar with the [[Policies|policies]] of the PostgreSQL community.

Oracle to Postgres Conversion

2012-06-21T19:48:12Z

Dfetter: /* CLOBs */

Note: This page was originally carried on the [http://openacs.org/ OpenACS] Website, but seems to have been lost over the ages and so is now reproduced here.
by James Shannon, Ben Adida, and Don Baccus

= What you should know before you begin =

You should know SQL relatively well. Knowing the details of Oracle SQL and Postgres SQL are obviously tremendous advantages, but the hints in this document should quickly bring you up to speed on what the differences are.

If you're porting Oracle SQL to Postgres SQL for the
[http://acspg.benadida.com/ ACS/pg], you should also be quite familiar with AOLserver Tcl, especially the AOLserver database APIs.

In this document, we're talking about:

* Oracle 8 and 8i
* Postgres 8.4, and sometimes this also works for earlier versions.

= Grammar Differences =

There are a handful of grammar differences in Postgres for functionality that is actually the same. ACS/pg attempts to perform these changes automatically, leaving only the major functionality differences to be ported by hand. This is done by db_sql_prep which performs a number of regular expression substitutions on a piece of SQL.

[[Category:Oracle]]

== Sysdate ==

Oracle uses the keyword sysdate to denote the current date and time. Postgres uses 'now'::datetime, which ACS/pg has conveniently wrapped in a function named sysdate().

ACS/pg also includes a Tcl procedure named db_sysdate which should be used every time the sysdate term appears. Thus:

set now [database_to_tcl_string $db "select sysdate from dual"]

should become

set now [database_to_tcl_string $db "select [db_sysdate] from dual"]

== The Dual Table ==

Oracle uses the "fake" dual table for many selects. This table was created in postgres as a view to ease porting problems. This allows code to remain somewhat compatible with Oracle SQL without annoying the Postgres parser.

== Sequences ==

Oracle's sequence grammar is sequence_name.nextval.

Postgres's sequence grammar is nextval('sequence_name').

In Tcl, getting the next sequence value can be abstracted by calling [db_sequence_nextval $db sequence_name]. In case you need to include a sequence's value in a more complex SQL statement, you can use [db_sequence_nextval_sql sequence_name] which will return the appropriate grammar.

== Decode ==

Oracle's handy decode function works as follows:

decode(expr, search, expr[, search, expr...] [, default])

To evaluate this expression, Oracle compares expr to each search value one by
one. If expr is equal to a search, Oracle returns the corresponding result. If
no match is found, Oracle returns default, or, if default is omitted, returns
null.

Postgres doesn't have the same construct. It can be replicated with:

CASE WHEN expr THEN expr [...] ELSE expr END

which returns the expression corresponding to the first true predicate. For example:

CASE WHEN c1 = 1 THEN 'match' ELSE 'no match' END

== NVL ==

Oracle has another handy function: NVL. NVL returns its first argument if it is not null, otherwise it returns its second argument.

start_date := NVL(hire_date, SYSDATE);

The above statement will return SYSDATE if hire_date is null. Postgres has a function that performs the same thing in a more generalized way: coalesce(expr1, expr2, expr3,....) returns the first non-null expression that is passed to it.

== Subquery in FROM ==

PostgreSQL requires a sub-SELECT surrounded by parentheses, and an alias '''must''' be provided for it. The alias is not mandatory for Oracle.

a query for Oracle:
SELECT * FROM (SELECT * FROM table_a)
in PostgreSQL will look like:
SELECT * FROM (SELECT * FROM table_a) as foo

= Functional Differences =

Postgres doesn't have all the functionality of Oracle. ACS/pg is forced to deal with these limitations with specific work-arounds. Almost everything can be done under Postgres, but some features are awaiting new versions of the open-source database.

== Outer Joins ==

Outer Joins in Oracle work as follows:

select a.field1, b.field2
from a, b
where a.item_id = b.item_id(+)

where the (+) indicates that, if there is no row in table b that matches the correct item_id, the match should still happen, with an empty row from table b. In this case, for example, for all rows in table a where there is no matching row in b, a row will still be returned where a.field1 is correct, but b.field2 is null.

In Postgresql:

select a.field1, b.field2
from a
left outer join b
on a.item_id = b.item_id;

In certain other cases where only aggregate values are pulled out of the outer-joined table, it's possible to not use a join at all. If the original query is:

select a.field1, sum(b.field2)
from a, b
where a.item_id = b.item_id (+)
group by a.field1

then the Postgres query can look like:

select a.field1, b_sum_field2_by_item_id(a.item_id)
from a

where you've defined the function:

create function b_sum_field2_by_item_id(integer)
returns integer
as '
DECLARE
v_item_id alias for $1;
BEGIN
return sum(field2) from b where item_id= v_item_id;
END;
' language 'plpgsql';

== CONNECT BY ==
Postgres doesn't have connect by statements. It does, however, have WITH RECURSIVE. As WITH RECURSIVE is Turing-complete, it is simple to translate CONNECT BY statements into WITH RECURSIVE ones.

== CLOBs ==
Postgres has decent CLOB support in the form of TEXT.

== BLOBs ==
Binary large object support in Postgres is very poor and unsuitable for use in a 24/7 environment, because you can't dump them with pg_dump. Backing up a database that makes use of Postgres large objects requires one to knock down the RDBMS and dump the files in the database directory.

Don Baccus put together a hack that extends AOLserver's postgres driver with BLOB-like support, by uuencoding/decoding binary files before stuffing them into or extracting them from the database. The resulting objects can be consistently dumped by "pg_dump" while the RDBMS is up and running. There is no need to interrupt service while making your backup.

To get around the one-block limit on the size of a tuple imposed by Postgres, the driver segments the encoded data into 8K chunks.

Postgres large objects are scheduled for a major overhaul in summer 2000. Because of this, only the BLOB functionality used by the ACS was implemented.

To use the BLOB driver extension, you must first create a column of type "integer" with the name "lob" in the table that will store the BLOB, and a trigger on it that calls "on_lob_ref". You must use the name "lob". Here's an example:

create table my_table (
my_key integer primary key,
lob integer references lobs,
my_other_data some_type -- etc
);

create trigger my_table_lob_trig before insert or delete or update
on my_table for each row execute procedure on_lob_ref();

To put a binary file into "my_table":

set lob [database_to_tcl_string $db "select empty_lob()"]

ns_db dml $db "begin"
ns_db dml $db "update my_table set lob = $lob where my_key = $my_key"
ns_pg blob_dml_file $db $lob $tmp_filename
ns_db dml $db "end"

Note that the call to ns_pg to stuff the file into the database MUST be wrapped in a transaction, even if you're not updating any other tables at the same time. The driver will return an error if you don't.

To return a large object stored in "my_table" to the user:

set lob [database_to_tcl_string $db "select lob from my_table
where my_key = $my_key"]
ns_pg blob_write $db $lob

Note that you don't need to wrap the call to blob_write in a transaction, as the database isn't being modified.

The large objects are automatically deleted when no longer used. To replace the large object stored in an existing record, just allocate a new one by calling "empty_lob()" and assign the returned key to the "lob" column in your table.

= External Tools =
A couple of extension tools are available for Oracle migration.

; [http://www.easyfrom.net/ ESF Database Migration Toolkit]
: A toolkit migrates Oracle databae to PostgreSQL in wizard. It connects to Oracle and PostgreSQL database directly, and migrate its table structure, data, indexes, primary keys, foreign keys, comments and so on.
; [http://orafce.projects.postgresql.org/ orafce]
: The goal of the project is to implement some functions from Oracle database. Some date functions (next_day, last_day, trunc, round, ...), string functions and some modules (DBMS_ALERT, DBMS_OUTPUT, UTL_FILE, DBMS_PIPE, ...) are implemented now. Functionality was verified on Oracle 10g and module is useful for production work.
; [http://pgfoundry.org/projects/ora2pg ora2pg]
: Ora2Pg is a Perl module to export an Oracle database schema to a PostgreSQL compatible schema. It connects your Oracle database, extracts its structure, and generates an SQL script that you can load into your PostgreSQL database.

Oracle to Postgres Conversion

2012-06-21T19:47:08Z

Dfetter: /* What you should know before you begin */

Note: This page was originally carried on the [http://openacs.org/ OpenACS] Website, but seems to have been lost over the ages and so is now reproduced here.
by James Shannon, Ben Adida, and Don Baccus

= What you should know before you begin =

You should know SQL relatively well. Knowing the details of Oracle SQL and Postgres SQL are obviously tremendous advantages, but the hints in this document should quickly bring you up to speed on what the differences are.

If you're porting Oracle SQL to Postgres SQL for the
[http://acspg.benadida.com/ ACS/pg], you should also be quite familiar with AOLserver Tcl, especially the AOLserver database APIs.

In this document, we're talking about:

* Oracle 8 and 8i
* Postgres 8.4, and sometimes this also works for earlier versions.

= Grammar Differences =

There are a handful of grammar differences in Postgres for functionality that is actually the same. ACS/pg attempts to perform these changes automatically, leaving only the major functionality differences to be ported by hand. This is done by db_sql_prep which performs a number of regular expression substitutions on a piece of SQL.

[[Category:Oracle]]

== Sysdate ==

Oracle uses the keyword sysdate to denote the current date and time. Postgres uses 'now'::datetime, which ACS/pg has conveniently wrapped in a function named sysdate().

ACS/pg also includes a Tcl procedure named db_sysdate which should be used every time the sysdate term appears. Thus:

set now [database_to_tcl_string $db "select sysdate from dual"]

should become

set now [database_to_tcl_string $db "select [db_sysdate] from dual"]

== The Dual Table ==

Oracle uses the "fake" dual table for many selects. This table was created in postgres as a view to ease porting problems. This allows code to remain somewhat compatible with Oracle SQL without annoying the Postgres parser.

== Sequences ==

Oracle's sequence grammar is sequence_name.nextval.

Postgres's sequence grammar is nextval('sequence_name').

In Tcl, getting the next sequence value can be abstracted by calling [db_sequence_nextval $db sequence_name]. In case you need to include a sequence's value in a more complex SQL statement, you can use [db_sequence_nextval_sql sequence_name] which will return the appropriate grammar.

== Decode ==

Oracle's handy decode function works as follows:

decode(expr, search, expr[, search, expr...] [, default])

To evaluate this expression, Oracle compares expr to each search value one by
one. If expr is equal to a search, Oracle returns the corresponding result. If
no match is found, Oracle returns default, or, if default is omitted, returns
null.

Postgres doesn't have the same construct. It can be replicated with:

CASE WHEN expr THEN expr [...] ELSE expr END

which returns the expression corresponding to the first true predicate. For example:

CASE WHEN c1 = 1 THEN 'match' ELSE 'no match' END

== NVL ==

Oracle has another handy function: NVL. NVL returns its first argument if it is not null, otherwise it returns its second argument.

start_date := NVL(hire_date, SYSDATE);

The above statement will return SYSDATE if hire_date is null. Postgres has a function that performs the same thing in a more generalized way: coalesce(expr1, expr2, expr3,....) returns the first non-null expression that is passed to it.

== Subquery in FROM ==

PostgreSQL requires a sub-SELECT surrounded by parentheses, and an alias '''must''' be provided for it. The alias is not mandatory for Oracle.

a query for Oracle:
SELECT * FROM (SELECT * FROM table_a)
in PostgreSQL will look like:
SELECT * FROM (SELECT * FROM table_a) as foo

= Functional Differences =

Postgres doesn't have all the functionality of Oracle. ACS/pg is forced to deal with these limitations with specific work-arounds. Almost everything can be done under Postgres, but some features are awaiting new versions of the open-source database.

== Outer Joins ==

Outer Joins in Oracle work as follows:

select a.field1, b.field2
from a, b
where a.item_id = b.item_id(+)

where the (+) indicates that, if there is no row in table b that matches the correct item_id, the match should still happen, with an empty row from table b. In this case, for example, for all rows in table a where there is no matching row in b, a row will still be returned where a.field1 is correct, but b.field2 is null.

In Postgresql:

select a.field1, b.field2
from a
left outer join b
on a.item_id = b.item_id;

In certain other cases where only aggregate values are pulled out of the outer-joined table, it's possible to not use a join at all. If the original query is:

select a.field1, sum(b.field2)
from a, b
where a.item_id = b.item_id (+)
group by a.field1

then the Postgres query can look like:

select a.field1, b_sum_field2_by_item_id(a.item_id)
from a

where you've defined the function:

create function b_sum_field2_by_item_id(integer)
returns integer
as '
DECLARE
v_item_id alias for $1;
BEGIN
return sum(field2) from b where item_id= v_item_id;
END;
' language 'plpgsql';

== CONNECT BY ==
Postgres doesn't have connect by statements. It does, however, have WITH RECURSIVE. As WITH RECURSIVE is Turing-complete, it is simple to translate CONNECT BY statements into WITH RECURSIVE ones.

== CLOBs ==
Postgres doesn't have decent CLOB support. However, with the lztext extension coming with Postgres 7.0, there is no need for CLOBs in the ACS/pg. We'll be able to do everything using varchars. For now, we're using only varchar(4000).

== BLOBs ==
Binary large object support in Postgres is very poor and unsuitable for use in a 24/7 environment, because you can't dump them with pg_dump. Backing up a database that makes use of Postgres large objects requires one to knock down the RDBMS and dump the files in the database directory.

Don Baccus put together a hack that extends AOLserver's postgres driver with BLOB-like support, by uuencoding/decoding binary files before stuffing them into or extracting them from the database. The resulting objects can be consistently dumped by "pg_dump" while the RDBMS is up and running. There is no need to interrupt service while making your backup.

To get around the one-block limit on the size of a tuple imposed by Postgres, the driver segments the encoded data into 8K chunks.

Postgres large objects are scheduled for a major overhaul in summer 2000. Because of this, only the BLOB functionality used by the ACS was implemented.

To use the BLOB driver extension, you must first create a column of type "integer" with the name "lob" in the table that will store the BLOB, and a trigger on it that calls "on_lob_ref". You must use the name "lob". Here's an example:

create table my_table (
my_key integer primary key,
lob integer references lobs,
my_other_data some_type -- etc
);

create trigger my_table_lob_trig before insert or delete or update
on my_table for each row execute procedure on_lob_ref();

To put a binary file into "my_table":

set lob [database_to_tcl_string $db "select empty_lob()"]

ns_db dml $db "begin"
ns_db dml $db "update my_table set lob = $lob where my_key = $my_key"
ns_pg blob_dml_file $db $lob $tmp_filename
ns_db dml $db "end"

Note that the call to ns_pg to stuff the file into the database MUST be wrapped in a transaction, even if you're not updating any other tables at the same time. The driver will return an error if you don't.

To return a large object stored in "my_table" to the user:

set lob [database_to_tcl_string $db "select lob from my_table
where my_key = $my_key"]
ns_pg blob_write $db $lob

Note that you don't need to wrap the call to blob_write in a transaction, as the database isn't being modified.

The large objects are automatically deleted when no longer used. To replace the large object stored in an existing record, just allocate a new one by calling "empty_lob()" and assign the returned key to the "lob" column in your table.

= External Tools =
A couple of extension tools are available for Oracle migration.

; [http://www.easyfrom.net/ ESF Database Migration Toolkit]
: A toolkit migrates Oracle databae to PostgreSQL in wizard. It connects to Oracle and PostgreSQL database directly, and migrate its table structure, data, indexes, primary keys, foreign keys, comments and so on.
; [http://orafce.projects.postgresql.org/ orafce]
: The goal of the project is to implement some functions from Oracle database. Some date functions (next_day, last_day, trunc, round, ...), string functions and some modules (DBMS_ALERT, DBMS_OUTPUT, UTL_FILE, DBMS_PIPE, ...) are implemented now. Functionality was verified on Oracle 10g and module is useful for production work.
; [http://pgfoundry.org/projects/ora2pg ora2pg]
: Ora2Pg is a Perl module to export an Oracle database schema to a PostgreSQL compatible schema. It connects your Oracle database, extracts its structure, and generates an SQL script that you can load into your PostgreSQL database.

Oracle to Postgres Conversion

2012-06-21T19:35:55Z

Dfetter: /* Connect By */

Note: This page was originally carried on the [http://openacs.org/ OpenACS] Website, but seems to have been lost over the ages and so is now reproduced here.
by James Shannon, Ben Adida, and Don Baccus

= What you should know before you begin =

You should know SQL relatively well. Knowing the details of Oracle SQL and Postgres SQL are obviously tremendous advantages, but the hints in this document should quickly bring you up to speed on what the differences are.

If you're porting Oracle SQL to Postgres SQL for the
[http://acspg.benadida.com/ ACS/pg], you should also be quite familiar with AOLserver Tcl, especially the AOLserver database APIs.

In this document, we're talking about:

* Oracle 8 and 8i
* Postgres 7.0, and sometimes this also works for Postgres 6.5.3

= Grammar Differences =

There are a handful of grammar differences in Postgres for functionality that is actually the same. ACS/pg attempts to perform these changes automatically, leaving only the major functionality differences to be ported by hand. This is done by db_sql_prep which performs a number of regular expression substitutions on a piece of SQL.

[[Category:Oracle]]

== Sysdate ==

Oracle uses the keyword sysdate to denote the current date and time. Postgres uses 'now'::datetime, which ACS/pg has conveniently wrapped in a function named sysdate().

ACS/pg also includes a Tcl procedure named db_sysdate which should be used every time the sysdate term appears. Thus:

set now [database_to_tcl_string $db "select sysdate from dual"]

should become

set now [database_to_tcl_string $db "select [db_sysdate] from dual"]

== The Dual Table ==

Oracle uses the "fake" dual table for many selects. This table was created in postgres as a view to ease porting problems. This allows code to remain somewhat compatible with Oracle SQL without annoying the Postgres parser.

== Sequences ==

Oracle's sequence grammar is sequence_name.nextval.

Postgres's sequence grammar is nextval('sequence_name').

In Tcl, getting the next sequence value can be abstracted by calling [db_sequence_nextval $db sequence_name]. In case you need to include a sequence's value in a more complex SQL statement, you can use [db_sequence_nextval_sql sequence_name] which will return the appropriate grammar.

== Decode ==

Oracle's handy decode function works as follows:

decode(expr, search, expr[, search, expr...] [, default])

To evaluate this expression, Oracle compares expr to each search value one by
one. If expr is equal to a search, Oracle returns the corresponding result. If
no match is found, Oracle returns default, or, if default is omitted, returns
null.

Postgres doesn't have the same construct. It can be replicated with:

CASE WHEN expr THEN expr [...] ELSE expr END

which returns the expression corresponding to the first true predicate. For example:

CASE WHEN c1 = 1 THEN 'match' ELSE 'no match' END

== NVL ==

Oracle has another handy function: NVL. NVL returns its first argument if it is not null, otherwise it returns its second argument.

start_date := NVL(hire_date, SYSDATE);

The above statement will return SYSDATE if hire_date is null. Postgres has a function that performs the same thing in a more generalized way: coalesce(expr1, expr2, expr3,....) returns the first non-null expression that is passed to it.

== Subquery in FROM ==

PostgreSQL requires a sub-SELECT surrounded by parentheses, and an alias '''must''' be provided for it. The alias is not mandatory for Oracle.

a query for Oracle:
SELECT * FROM (SELECT * FROM table_a)
in PostgreSQL will look like:
SELECT * FROM (SELECT * FROM table_a) as foo

= Functional Differences =

Postgres doesn't have all the functionality of Oracle. ACS/pg is forced to deal with these limitations with specific work-arounds. Almost everything can be done under Postgres, but some features are awaiting new versions of the open-source database.

== Outer Joins ==

Outer Joins in Oracle work as follows:

select a.field1, b.field2
from a, b
where a.item_id = b.item_id(+)

where the (+) indicates that, if there is no row in table b that matches the correct item_id, the match should still happen, with an empty row from table b. In this case, for example, for all rows in table a where there is no matching row in b, a row will still be returned where a.field1 is correct, but b.field2 is null.

In Postgresql:

select a.field1, b.field2
from a
left outer join b
on a.item_id = b.item_id;

In certain other cases where only aggregate values are pulled out of the outer-joined table, it's possible to not use a join at all. If the original query is:

select a.field1, sum(b.field2)
from a, b
where a.item_id = b.item_id (+)
group by a.field1

then the Postgres query can look like:

select a.field1, b_sum_field2_by_item_id(a.item_id)
from a

where you've defined the function:

create function b_sum_field2_by_item_id(integer)
returns integer
as '
DECLARE
v_item_id alias for $1;
BEGIN
return sum(field2) from b where item_id= v_item_id;
END;
' language 'plpgsql';

== CONNECT BY ==
Postgres doesn't have connect by statements. It does, however, have WITH RECURSIVE. As WITH RECURSIVE is Turing-complete, it is simple to translate CONNECT BY statements into WITH RECURSIVE ones.

== CLOBs ==
Postgres doesn't have decent CLOB support. However, with the lztext extension coming with Postgres 7.0, there is no need for CLOBs in the ACS/pg. We'll be able to do everything using varchars. For now, we're using only varchar(4000).

== BLOBs ==
Binary large object support in Postgres is very poor and unsuitable for use in a 24/7 environment, because you can't dump them with pg_dump. Backing up a database that makes use of Postgres large objects requires one to knock down the RDBMS and dump the files in the database directory.

Don Baccus put together a hack that extends AOLserver's postgres driver with BLOB-like support, by uuencoding/decoding binary files before stuffing them into or extracting them from the database. The resulting objects can be consistently dumped by "pg_dump" while the RDBMS is up and running. There is no need to interrupt service while making your backup.

To get around the one-block limit on the size of a tuple imposed by Postgres, the driver segments the encoded data into 8K chunks.

Postgres large objects are scheduled for a major overhaul in summer 2000. Because of this, only the BLOB functionality used by the ACS was implemented.

To use the BLOB driver extension, you must first create a column of type "integer" with the name "lob" in the table that will store the BLOB, and a trigger on it that calls "on_lob_ref". You must use the name "lob". Here's an example:

create table my_table (
my_key integer primary key,
lob integer references lobs,
my_other_data some_type -- etc
);

create trigger my_table_lob_trig before insert or delete or update
on my_table for each row execute procedure on_lob_ref();

To put a binary file into "my_table":

set lob [database_to_tcl_string $db "select empty_lob()"]

ns_db dml $db "begin"
ns_db dml $db "update my_table set lob = $lob where my_key = $my_key"
ns_pg blob_dml_file $db $lob $tmp_filename
ns_db dml $db "end"

Note that the call to ns_pg to stuff the file into the database MUST be wrapped in a transaction, even if you're not updating any other tables at the same time. The driver will return an error if you don't.

To return a large object stored in "my_table" to the user:

set lob [database_to_tcl_string $db "select lob from my_table
where my_key = $my_key"]
ns_pg blob_write $db $lob

Note that you don't need to wrap the call to blob_write in a transaction, as the database isn't being modified.

The large objects are automatically deleted when no longer used. To replace the large object stored in an existing record, just allocate a new one by calling "empty_lob()" and assign the returned key to the "lob" column in your table.

= External Tools =
A couple of extension tools are available for Oracle migration.

; [http://www.easyfrom.net/ ESF Database Migration Toolkit]
: A toolkit migrates Oracle databae to PostgreSQL in wizard. It connects to Oracle and PostgreSQL database directly, and migrate its table structure, data, indexes, primary keys, foreign keys, comments and so on.
; [http://orafce.projects.postgresql.org/ orafce]
: The goal of the project is to implement some functions from Oracle database. Some date functions (next_day, last_day, trunc, round, ...), string functions and some modules (DBMS_ALERT, DBMS_OUTPUT, UTL_FILE, DBMS_PIPE, ...) are implemented now. Functionality was verified on Oracle 10g and module is useful for production work.
; [http://pgfoundry.org/projects/ora2pg ora2pg]
: Ora2Pg is a Perl module to export an Oracle database schema to a PostgreSQL compatible schema. It connects your Oracle database, extracts its structure, and generates an SQL script that you can load into your PostgreSQL database.

Oracle to Postgres Conversion

2012-06-21T19:35:38Z

Dfetter: /* Connect By */

Note: This page was originally carried on the [http://openacs.org/ OpenACS] Website, but seems to have been lost over the ages and so is now reproduced here.
by James Shannon, Ben Adida, and Don Baccus

= What you should know before you begin =

You should know SQL relatively well. Knowing the details of Oracle SQL and Postgres SQL are obviously tremendous advantages, but the hints in this document should quickly bring you up to speed on what the differences are.

If you're porting Oracle SQL to Postgres SQL for the
[http://acspg.benadida.com/ ACS/pg], you should also be quite familiar with AOLserver Tcl, especially the AOLserver database APIs.

In this document, we're talking about:

* Oracle 8 and 8i
* Postgres 7.0, and sometimes this also works for Postgres 6.5.3

= Grammar Differences =

There are a handful of grammar differences in Postgres for functionality that is actually the same. ACS/pg attempts to perform these changes automatically, leaving only the major functionality differences to be ported by hand. This is done by db_sql_prep which performs a number of regular expression substitutions on a piece of SQL.

[[Category:Oracle]]

== Sysdate ==

Oracle uses the keyword sysdate to denote the current date and time. Postgres uses 'now'::datetime, which ACS/pg has conveniently wrapped in a function named sysdate().

ACS/pg also includes a Tcl procedure named db_sysdate which should be used every time the sysdate term appears. Thus:

set now [database_to_tcl_string $db "select sysdate from dual"]

should become

set now [database_to_tcl_string $db "select [db_sysdate] from dual"]

== The Dual Table ==

Oracle uses the "fake" dual table for many selects. This table was created in postgres as a view to ease porting problems. This allows code to remain somewhat compatible with Oracle SQL without annoying the Postgres parser.

== Sequences ==

Oracle's sequence grammar is sequence_name.nextval.

Postgres's sequence grammar is nextval('sequence_name').

In Tcl, getting the next sequence value can be abstracted by calling [db_sequence_nextval $db sequence_name]. In case you need to include a sequence's value in a more complex SQL statement, you can use [db_sequence_nextval_sql sequence_name] which will return the appropriate grammar.

== Decode ==

Oracle's handy decode function works as follows:

decode(expr, search, expr[, search, expr...] [, default])

To evaluate this expression, Oracle compares expr to each search value one by
one. If expr is equal to a search, Oracle returns the corresponding result. If
no match is found, Oracle returns default, or, if default is omitted, returns
null.

Postgres doesn't have the same construct. It can be replicated with:

CASE WHEN expr THEN expr [...] ELSE expr END

which returns the expression corresponding to the first true predicate. For example:

CASE WHEN c1 = 1 THEN 'match' ELSE 'no match' END

== NVL ==

Oracle has another handy function: NVL. NVL returns its first argument if it is not null, otherwise it returns its second argument.

start_date := NVL(hire_date, SYSDATE);

The above statement will return SYSDATE if hire_date is null. Postgres has a function that performs the same thing in a more generalized way: coalesce(expr1, expr2, expr3,....) returns the first non-null expression that is passed to it.

== Subquery in FROM ==

PostgreSQL requires a sub-SELECT surrounded by parentheses, and an alias '''must''' be provided for it. The alias is not mandatory for Oracle.

a query for Oracle:
SELECT * FROM (SELECT * FROM table_a)
in PostgreSQL will look like:
SELECT * FROM (SELECT * FROM table_a) as foo

= Functional Differences =

Postgres doesn't have all the functionality of Oracle. ACS/pg is forced to deal with these limitations with specific work-arounds. Almost everything can be done under Postgres, but some features are awaiting new versions of the open-source database.

== Outer Joins ==

Outer Joins in Oracle work as follows:

select a.field1, b.field2
from a, b
where a.item_id = b.item_id(+)

where the (+) indicates that, if there is no row in table b that matches the correct item_id, the match should still happen, with an empty row from table b. In this case, for example, for all rows in table a where there is no matching row in b, a row will still be returned where a.field1 is correct, but b.field2 is null.

In Postgresql:

select a.field1, b.field2
from a
left outer join b
on a.item_id = b.item_id;

In certain other cases where only aggregate values are pulled out of the outer-joined table, it's possible to not use a join at all. If the original query is:

select a.field1, sum(b.field2)
from a, b
where a.item_id = b.item_id (+)
group by a.field1

then the Postgres query can look like:

select a.field1, b_sum_field2_by_item_id(a.item_id)
from a

where you've defined the function:

create function b_sum_field2_by_item_id(integer)
returns integer
as '
DECLARE
v_item_id alias for $1;
BEGIN
return sum(field2) from b where item_id= v_item_id;
END;
' language 'plpgsql';

== Connect By ==
Postgres doesn't have connect by statements. It does, however, have WITH RECURSIVE. As WITH RECURSIVE is Turing-complete, it is simple to translate CONNECT BY statements into WITH RECURSIVE ones.

== CLOBs ==
Postgres doesn't have decent CLOB support. However, with the lztext extension coming with Postgres 7.0, there is no need for CLOBs in the ACS/pg. We'll be able to do everything using varchars. For now, we're using only varchar(4000).

== BLOBs ==
Binary large object support in Postgres is very poor and unsuitable for use in a 24/7 environment, because you can't dump them with pg_dump. Backing up a database that makes use of Postgres large objects requires one to knock down the RDBMS and dump the files in the database directory.

Don Baccus put together a hack that extends AOLserver's postgres driver with BLOB-like support, by uuencoding/decoding binary files before stuffing them into or extracting them from the database. The resulting objects can be consistently dumped by "pg_dump" while the RDBMS is up and running. There is no need to interrupt service while making your backup.

To get around the one-block limit on the size of a tuple imposed by Postgres, the driver segments the encoded data into 8K chunks.

Postgres large objects are scheduled for a major overhaul in summer 2000. Because of this, only the BLOB functionality used by the ACS was implemented.

To use the BLOB driver extension, you must first create a column of type "integer" with the name "lob" in the table that will store the BLOB, and a trigger on it that calls "on_lob_ref". You must use the name "lob". Here's an example:

create table my_table (
my_key integer primary key,
lob integer references lobs,
my_other_data some_type -- etc
);

create trigger my_table_lob_trig before insert or delete or update
on my_table for each row execute procedure on_lob_ref();

To put a binary file into "my_table":

set lob [database_to_tcl_string $db "select empty_lob()"]

ns_db dml $db "begin"
ns_db dml $db "update my_table set lob = $lob where my_key = $my_key"
ns_pg blob_dml_file $db $lob $tmp_filename
ns_db dml $db "end"

Note that the call to ns_pg to stuff the file into the database MUST be wrapped in a transaction, even if you're not updating any other tables at the same time. The driver will return an error if you don't.

To return a large object stored in "my_table" to the user:

set lob [database_to_tcl_string $db "select lob from my_table
where my_key = $my_key"]
ns_pg blob_write $db $lob

Note that you don't need to wrap the call to blob_write in a transaction, as the database isn't being modified.

The large objects are automatically deleted when no longer used. To replace the large object stored in an existing record, just allocate a new one by calling "empty_lob()" and assign the returned key to the "lob" column in your table.

= External Tools =
A couple of extension tools are available for Oracle migration.

; [http://www.easyfrom.net/ ESF Database Migration Toolkit]
: A toolkit migrates Oracle databae to PostgreSQL in wizard. It connects to Oracle and PostgreSQL database directly, and migrate its table structure, data, indexes, primary keys, foreign keys, comments and so on.
; [http://orafce.projects.postgresql.org/ orafce]
: The goal of the project is to implement some functions from Oracle database. Some date functions (next_day, last_day, trunc, round, ...), string functions and some modules (DBMS_ALERT, DBMS_OUTPUT, UTL_FILE, DBMS_PIPE, ...) are implemented now. Functionality was verified on Oracle 10g and module is useful for production work.
; [http://pgfoundry.org/projects/ora2pg ora2pg]
: Ora2Pg is a Perl module to export an Oracle database schema to a PostgreSQL compatible schema. It connects your Oracle database, extracts its structure, and generates an SQL script that you can load into your PostgreSQL database.

Committers

2012-06-08T17:59:33Z

Dfetter:

This is the current list of people with access to push to the git repository with their user names. For technical details on how committing works, see [[Committing with Git]]. Note: This is just a list of people who currently have access to push to git; for information on current and previous contributors, see the [http://www.postgresql.org/community/contributors/ contributor profiles] section of the web site. Note: The names are listed here in order of first commit, oldest first; this isn't intended to imply anything about depth of contribution.

* Marc G. Fournier (scrappy)
* Bruce Momjian (momjian)
* Tom Lane (tgl)
* Jan Wieck (wieck)
* Michael Meskes (meskes)
* Tatsuo Ishii (ishii)
* Peter Eisentraut (petere)
* D'Arcy J.M. Cain (darcy)
* Teodor Sigaev (teodor)
* Joe Conway (joe)
* Neil Conway (neilc)
* Alvaro Herrera (alvherre)
* Andrew Dunstan (adunstan)
* Magnus Hagander (mha)
* Heikki Linnakangas (heikki)
* Robert Haas (rhaas)
* Itagaki Takahiro (itagaki)
* Simon Riggs (sriggs)
* Greg Stark (stark)
* Kevin Grittner (kgrittn)

== Notes on the Commit Log ==

Hundreds of developers have successfully contributed work to PostgreSQL over more than 20 years, many acting as individuals, though also many representing academic institutions and both user and vendor companies. Both the "Author" and "Committer" fields of such patches will reflect the committer. The actual author of a patch, if different, is generally listed in the commit message; reviewers or others who contributed ideas or otherwise helped with the patch may also be listed. Many patches, in the form in which they are committed, are the work of multiple people: original author or authors, reviewer(s), and/or committer. As a result, no simple analysis of duration or depth of contribution over time is possible from the commit log. The project operates a system of careful peer review and even committers have their work checked by other committers and the community as a whole.

== New Committers ==

There is no defined process for how new committers are selected. Typically, candidates will have sent many good patches over a longer period of time. Then, existing committers or the core team will propose making the person a committer. The final approval is done by the core team.

[[Category:Community]]

Committers

2012-06-08T17:59:19Z

Dfetter:

This is the current list of people with access to push to the git repository with their user names. For technical details on how committing works, see [[Committing with Git]]. Note: This is just a list of people who currently have access to push to git; for information on current and previous contributors, see the [http://www.postgresql.org/community/contributors/ contributor profiles] section of the web site. Note: The names are listed here in order of first commit, oldest first; this isn't intended to imply anything about depth of contribution.

* Marc G. Fournier (scrappy)
* Bruce Momjian (momjian)
* Tom Lane (tgl)
* Jan Wieck (wieck)
* Michael Meskes (meskes)
* Tatsuo Ishii (ishii)
* Peter Eisentraut (petere)
* D'Arcy J.M. Cain (darcy)
* Teodor Sigaev (teodor)
* Joe Conway (joe)
* Neil Conway (neilc)
* Alvaro Herrera (alvherre)
* Andrew Dunstan (adunstan)
* Magnus Hagander (mha)
* Heikki Linnakangas (heikki)
* Robert Haas (rhaas)
* Itagaki Takahiro (itagaki)
* Simon Riggs (sriggs)
* Greg Stark (stark)
* Kevin Griggner (kgrittn)

== Notes on the Commit Log ==

Hundreds of developers have successfully contributed work to PostgreSQL over more than 20 years, many acting as individuals, though also many representing academic institutions and both user and vendor companies. Both the "Author" and "Committer" fields of such patches will reflect the committer. The actual author of a patch, if different, is generally listed in the commit message; reviewers or others who contributed ideas or otherwise helped with the patch may also be listed. Many patches, in the form in which they are committed, are the work of multiple people: original author or authors, reviewer(s), and/or committer. As a result, no simple analysis of duration or depth of contribution over time is possible from the commit log. The project operates a system of careful peer review and even committers have their work checked by other committers and the community as a whole.

== New Committers ==

There is no defined process for how new committers are selected. Typically, candidates will have sent many good patches over a longer period of time. Then, existing committers or the core team will propose making the person a committer. The final approval is done by the core team.

[[Category:Community]]

PgCon2012CanadaClusterSummit

2012-05-15T02:41:21Z

Dfetter: /* Attendees */

= 3rd Postgres Cluster Hackers Summit, pgCon 2012 =

== Time and Place ==

Tuesday, May 15th, 10am to 5pm

Conference room at the University of Ottawa, room MRT 219

== Agenda ==

Draft agenda follows. Please let me know of any contributions/changes to the agenda you have:

=== Project Reports: 5 minutes from each project ===

10am to 11am

* Hot Standby/Binary Replication -- Simon
* pgPoolII -- Tatsuo
* PostgresXC -- Koichi
* Slony -- Jan
* Stado -- Jim

=== Technical Issues of common interest ===

11am to Noon, and 1pm to 5pm

* SSI in cluster/replication - Koichi, Kevin
* Parser export - Koichi, Tatsuo
* Managing consistent views of data - Koichi
* Command Triggers, Common API for logical replication - Dimitri
* Detecting database change caused by triggers and cascade operations - Tatsuo
* Fault detection and handling - Koichi
* Node addition/removal - Koichi
* Configuration and operation - Koichi
* Cursor in replication/multi master - Koichi
* Bi-Directional Replication - Simon

The Cluster Summit will be from 10am to 5pm, with a break for lunch, which will be provided, sponsored by NTT.

== Attendees ==

# Koichi Suzuki, Postgres-XC
# Álvaro Herrera, Mammoth, Postgres-XC
# Jim Mlodgenski, Stado
# Mason Sharp, Stado, Postgres-XC
# Dimitri Fontaine, Slony, Londiste, Bucardo
# Christopher Browne, Slony
# Steve Singer, Slony
# Kevin Grittner, SSI
# Simon Riggs, Binary Replication
# Michael Paquier, Postgres-XC
# Ashutosh Bapat, Postgres-XC
# Tatsuo Ishii, pgPool
# Kaori Inaba, pgPool
# Daichi Matsusaka, pgPool
# Guillaume Lelarge, pgPool
# David Wheeler
# Josh Berkus, moderator
# Tetsuo Sakata, Postgres-XC
# Andres Freund, Bi-Directional Replication
# Greg Smith, Bi-Directional Replication
# Jan Wieck, Slony
# David Fetter

=== Joining the Meeting ===

If you will be able to attend, please email Josh ([mailto:josh@agliodbs.com josh@agliodbs.com]) with the following:

* Your Name
* Project(s) you work on
* If you will be giving a Project Report
* If you have additions to the agenda
* Special dietary needs for lunch, if any
* If you need travel assistance

Note that the availability of travel funding is not guaranteed; I can just agree to request it.

Events

2012-05-07T21:24:13Z

Dfetter: /* PostgreSQL Events */

== PostgreSQL Events ==

Most PostgreSQL-specific events are tracked on the [http://www.postgresql.org/about/eventarchive PostgreSQL Events] page. This is a listing of events at which we expect, or would like to have, a PostgreSQL presence. Please keep the events in order by starting date and follow the existing examples. Please also tag the events with the MediaWiki "PostgreSQL Events" category. If you are going to be organizing a PostgreSQL booth, please adhere to [[BoothPolicies]]. PostgreSQL Europe conference coordination [[PGUG EU Conference Coordination|is here]]. Conference for China user group [[Pg_envent_cn| is here]].

{| border="1"
|+
|- style="background:Khaki;"
'''Upcoming PostgreSQL Events Listing'''
| '''Event''' || '''Web Page''' || '''Date''' || '''Country''' || '''City''' || '''Activities'''
|-
| PGCon 2012 || [http://www.pgcon.org/2012/ PGCon 2012] || May 15-18, 2012 || Canada || Ottawa, ON || Training, Talks
|-
| PG Day France 2012 || [http://www.pgday.fr/ PG Day France 2012] || June 7, 2012 || France || Lyon || Talks
|-
| PG Conference China 2012 || [http://wiki.postgresql.org/wiki/Pgconfchina2012 PG Conference China 2012] || June 14-17, 2012 || China || Beijing || Training, Talks
|-
| PGOpen 2012 || [http://postgresopen.org Postgres Open 2012] || September 16-19, 2012 || USA || Chicago, IL || Training, Talks
|-
| PG Conference Europe 2012 || [http://2012.pgconf.eu PostgreSQL Conference 2012] || October 23-26, 2012 || Czech Rep. || Prague || Training, Talks
|}

{| border="1"
|+
|- style="background:Khaki;"
'''Previous PostgreSQL Events Listing'''
| '''Event''' || '''Web Page''' || '''Date''' || '''Country''' || '''City''' || '''Activities'''
|-
| PostgresSQL Conference 2012 Japan || [http://www.postgresql.jp/events/pgcon2012/top PostgreSQL Conference 2012 Japan] || February 24, 2012 || Japan || Tokyo || Talks
|-
| PGDay Austin 2012 || [http://pgday.austinpug.org PGDay Austin 2012] || March 28, 2012 || USA || Austin, TX || Talks
|-
| PGDay DC 2012 || [http://pgday.bwpug.org PGDay DC 2012] || March 30, 2012 || USA || Reston, VA || Talks
|-
| PGDay NYC 2012 || [http://pgday.nycpug.org PGDay NYC 2012] || April 2, 2012 || USA || New York, NY || Talks
|-
| [[FOSDEM 2012]] || [http://www.fosdem.org/2012/ FOSDEM '12] || February 04-05, 2012 || Belgium || Brussels || Booth, Devroom
|-
| PG Session #3 || [http://www.postgresql-sessions.org/3/ PG Session #3] || February 02 2012 || France || Paris || Talks
|-
| PostgreSQL Conference Germany 2011 || [http://2011.pgconf.de/ PGConf.DE 2011]|| Nov 11, 2011 || Germany || Oberhausen || [[German-Speaking PostgreSQL Conference 2011|Talks]]
|-
| PGBR2011 || [http://pgbr.postgresql.org.br/ PGBR2011] || Nov 3-4, 2011 || Brazil || São Paulo || Tutorials, Talks, Booth
|-
| PostgreSQL Conference Europe 2011 || [http://2011.pgconf.eu/ PGConf.EU 2011] || October 18-21, 2011 || The Netherlands || Amsterdam || Training, [[PostgreSQL Conference Europe Talks 2011|Talks]]
|-
| PostgreSQL Conference West 2011 || [http://www.postgresqlconference.org/ #PgWest 2011] || September 27-30, 2011 || San Jose || California || Training, Talks, Booth
|-
| Postgres Open || [http://postgresopen.org/2011/home/ Postgres Open 2011] || Sep 14-16, 2011 || USA || Chicago || [[Postgres Open Talks 2011]]
|-
| PGDay Porto Alegre || [http://www.postgresql.org.br/eventos/2011/pgday/rs PGDay Porto Alegre] || August 19, 2011 || Brazil || Porto Alegre || Talks, Booths
|-
| FrOSCon || [http://www.froscon.de/ FrOSCon 2011]|| August 20-21, 2011 || Germany || St. Augustin || Talks, Booth
|-
| Pg Conf Colombia || [http://www.pgconf.org Pg Conf Colombia 2011]|| August 4-5, 2011 || Colombia || Bucaramanga ||
|-
| PgDay at OSCON 2011 || [http://pugs.postgresql.org/node/1663 PgDay at OSCON 2011] || July 24, 2011 || USA || Portland, OR || Talks, party
|-
| 2011 China PostgreSQL User conference ||[http://wiki.postgresql.org/wiki/Pgconchina2011 2011 China PostgreSQL User conference] || July 16-17, 2011 || China || GUANGZHOU ||Talks,Tutorial
|-
| PGCon 2011 || [http://www.pgcon.org/2011/ PGCon 2011] || May 17-20, 2011 || Canada || Ottawa || Talks, Training
|-
| PGEast 2011 || [https://www.postgresqlconference.org/ PGWest] || March 22-25, 2011 || USA || New York, NY || Talks, Training
|-
| PostgresSQL Conference 2011 Japan || || February 25-26, 2011 || Tokyo || Japan ||
|-
| [[FOSDEM, Brussels 2011]] || [http://www.fosdem.org/2011/ FOSDEM '11] || February 05-06, 2011 || Belgium || Brussels || Booth, Devroom
|-
| [[PGDAY-Latino, La Habana 2011]] || [http://postgresql.uci.cu/news/19 PGDAY-Latino '11] || February 01-05, 2011 || Cuba || La Habana || Talks, Workshop
|-
| colspan="6" | [[Events/2010 | 2010 events]]
|-
| colspan="6" | [[Events/2009 | 2009 events]]
|-
| colspan="6" | [[Events/2008 | 2008 events]]
|-
| colspan="6" | [[Events/2007 | 2007 events]]
|}

== External Links ==

* [http://conferences.oreillynet.com/ O'Reilly conferences]
* [http://opencheese.com/2007/10/14/open-source-events-2008/ "Open Source and Linux events in 2008"]

[[Category:PostgreSQL Events]]
[[Category:Advocacy]]

Events

2012-05-07T21:22:54Z

Dfetter: /* PostgreSQL Events */

== PostgreSQL Events ==

Most PostgreSQL-specific events are tracked on the [http://www.postgresql.org/about/eventarchive PostgreSQL Events] page. This is a listing of events at which we expect, or would like to have, a PostgreSQL presence. Please keep the events in order by starting date and follow the existing examples. Please also tag the events with the MediaWiki "PostgreSQL Events" category. If you are going to be organizing a PostgreSQL booth, please adhere to [[BoothPolicies]]. PostgreSQL Europe conference coordination [[PGUG EU Conference Coordination|is here]]. Conference for China user group [[Pg_envent_cn| is here]].

{| border="1"
|+
|- style="background:Khaki;"
'''Upcoming PostgreSQL Events Listing'''
| '''Event''' || '''Web Page''' || '''Date''' || '''Country''' || '''City''' || '''Activities'''
|-
| PGCon 2012 || [http://www.pgcon.org/2012/ PGCon 2012] || May 15-18, 2012 || Canada || Ottawa, ON || Training, Talks
|-
| PG Day France 2012 || [http://www.pgday.fr/ PG Day France 2012] || June 7, 2012 || France || Lyon || Talks
|-
| PG Day China 2012 || [http://wiki.postgresql.org/wiki/Pgconfchina2012 PG Day China 2012] || June 14-17, 2012 || China || Beijing || Training, Talks
|-
| PGOpen 2012 || [http://postgresopen.org Postgres Open 2012] || September 16-19, 2012 || USA || Chicago, IL || Training, Talks
|-
| PG Conference Europe 2012 || [http://2012.pgconf.eu PostgreSQL Conference 2012] || October 23-26, 2012 || Czech Rep. || Prague || Training, Talks
|}

{| border="1"
|+
|- style="background:Khaki;"
'''Previous PostgreSQL Events Listing'''
| '''Event''' || '''Web Page''' || '''Date''' || '''Country''' || '''City''' || '''Activities'''
|-
| PostgresSQL Conference 2012 Japan || [http://www.postgresql.jp/events/pgcon2012/top PostgreSQL Conference 2012 Japan] || February 24, 2012 || Japan || Tokyo || Talks
|-
| PGDay Austin 2012 || [http://pgday.austinpug.org PGDay Austin 2012] || March 28, 2012 || USA || Austin, TX || Talks
|-
| PGDay DC 2012 || [http://pgday.bwpug.org PGDay DC 2012] || March 30, 2012 || USA || Reston, VA || Talks
|-
| PGDay NYC 2012 || [http://pgday.nycpug.org PGDay NYC 2012] || April 2, 2012 || USA || New York, NY || Talks
|-
| [[FOSDEM 2012]] || [http://www.fosdem.org/2012/ FOSDEM '12] || February 04-05, 2012 || Belgium || Brussels || Booth, Devroom
|-
| PG Session #3 || [http://www.postgresql-sessions.org/3/ PG Session #3] || February 02 2012 || France || Paris || Talks
|-
| PostgreSQL Conference Germany 2011 || [http://2011.pgconf.de/ PGConf.DE 2011]|| Nov 11, 2011 || Germany || Oberhausen || [[German-Speaking PostgreSQL Conference 2011|Talks]]
|-
| PGBR2011 || [http://pgbr.postgresql.org.br/ PGBR2011] || Nov 3-4, 2011 || Brazil || São Paulo || Tutorials, Talks, Booth
|-
| PostgreSQL Conference Europe 2011 || [http://2011.pgconf.eu/ PGConf.EU 2011] || October 18-21, 2011 || The Netherlands || Amsterdam || Training, [[PostgreSQL Conference Europe Talks 2011|Talks]]
|-
| PostgreSQL Conference West 2011 || [http://www.postgresqlconference.org/ #PgWest 2011] || September 27-30, 2011 || San Jose || California || Training, Talks, Booth
|-
| Postgres Open || [http://postgresopen.org/2011/home/ Postgres Open 2011] || Sep 14-16, 2011 || USA || Chicago || [[Postgres Open Talks 2011]]
|-
| PGDay Porto Alegre || [http://www.postgresql.org.br/eventos/2011/pgday/rs PGDay Porto Alegre] || August 19, 2011 || Brazil || Porto Alegre || Talks, Booths
|-
| FrOSCon || [http://www.froscon.de/ FrOSCon 2011]|| August 20-21, 2011 || Germany || St. Augustin || Talks, Booth
|-
| Pg Conf Colombia || [http://www.pgconf.org Pg Conf Colombia 2011]|| August 4-5, 2011 || Colombia || Bucaramanga ||
|-
| PgDay at OSCON 2011 || [http://pugs.postgresql.org/node/1663 PgDay at OSCON 2011] || July 24, 2011 || USA || Portland, OR || Talks, party
|-
| 2011 China PostgreSQL User conference ||[http://wiki.postgresql.org/wiki/Pgconchina2011 2011 China PostgreSQL User conference] || July 16-17, 2011 || China || GUANGZHOU ||Talks,Tutorial
|-
| PGCon 2011 || [http://www.pgcon.org/2011/ PGCon 2011] || May 17-20, 2011 || Canada || Ottawa || Talks, Training
|-
| PGEast 2011 || [https://www.postgresqlconference.org/ PGWest] || March 22-25, 2011 || USA || New York, NY || Talks, Training
|-
| PostgresSQL Conference 2011 Japan || || February 25-26, 2011 || Tokyo || Japan ||
|-
| [[FOSDEM, Brussels 2011]] || [http://www.fosdem.org/2011/ FOSDEM '11] || February 05-06, 2011 || Belgium || Brussels || Booth, Devroom
|-
| [[PGDAY-Latino, La Habana 2011]] || [http://postgresql.uci.cu/news/19 PGDAY-Latino '11] || February 01-05, 2011 || Cuba || La Habana || Talks, Workshop
|-
| colspan="6" | [[Events/2010 | 2010 events]]
|-
| colspan="6" | [[Events/2009 | 2009 events]]
|-
| colspan="6" | [[Events/2008 | 2008 events]]
|-
| colspan="6" | [[Events/2007 | 2007 events]]
|}

== External Links ==

* [http://conferences.oreillynet.com/ O'Reilly conferences]
* [http://opencheese.com/2007/10/14/open-source-events-2008/ "Open Source and Linux events in 2008"]

[[Category:PostgreSQL Events]]
[[Category:Advocacy]]

Pgconfchina2012

2012-05-07T21:20:33Z

Dfetter: s/Rigg/Riggs/

== PostgreSQL Conference China 2012 ==

PostgreSQL中国用户会全国大会是由PostgreSQL中国用户会(CPUG)主办的旨在促进PostgreSQL在中国发展的非营利性的会议年度大会，大会是分享PostgreSQL的最佳使用实践、学习最新的功能特性、结交本领域的朋友的最佳场所。

2012年度大会将于2012年6月14日-17日在北京举行，中国人民大学信息学院承办。其中6月14日-15日是面向初级人员的入门培训，6月16(周六),17(周日)日是正式大会。本次大会将邀请到社区的核心组员Magnus Hagander,主要开发人员Simon Riggs、PG-XC的首席架构师铃木幸一(Suzuki Koichi)及其他海外专家为本次大会分享最前沿的PostgreSQL方面的信息，同时还有业界的资深人员作相关演讲。

PostgresQL User Group Conference China which organized by CPUG(China Postgres User Group) is an annual conference for PostgreSQL users in China, the conference is a hub for learning new features, sharing the know-how, and making friends about PostgreSQL.

PostgresQL User Group Conference China 2012 will be on 14-17 June 2012 at Renmin University of China in Beijing with two days of Tutorials on 14-15 June 2012. Magnus Hagander,Simon Riggs and Suzuki Koichi from community will also join this conference to give keynote speachs.

== 信息 Information ==

'''日期 DATE''': June 14-17, 2012

'''地点 LOCATION''': 中国人民大学 Remin University of China, Beijing，China

'''地址 ADDRESS''':

'''主办 Endorsed by''': CPUG(China PostgreSQL User Group) 中国PostgreSQL用户会

'''承办 Organizer''': 中国人民大学信息学院

'''协办''': IT168盛拓传媒

'''赞助支持伙伴 SPONSORS''':

'''内容 TOPIC''': PostgreSQL的企业应用、架构设计、运维管理、应用开发

'''费用 FEE''': 公司名义：300RMB(由于大会目前缺乏赞助商，所以需要门票收费，解决资金不足问题, 具体预算见下面),个人名义：200RMB(不提供发票), 学生100RMB(需提供学生证,不提供发票)。

'''缴费方法 ''':
银行
开户人
账号：

注1：如需开发票，请发邮件联系 galylee at gmail.com
注2：本次缴费由PG中国用户会负责，与IT168无任何关系，如产生任何纠纷由PG中国用户会负责，有问题请直接联系李元佳 Galylee at gmail.com 13710389225。

'''餐费 Lunch FEE''' 自助餐 120元/人(两天) 如需预定请注明

'''其他赞助商'''

'''参加方法 REGISTRATION''':
：本届大会将由IT168负责本次大会的报名活动，届时请参考相关主页。

'''联系方式 CONTACT''':

如有任何疑问欢迎联系。
Please contact if you have any questions.
大会会务负责人 Conference Orginizer：李元佳 Galy Lee
手机 Mobile：+86-13710389225
邮件 Email：galylee at gmail.com

'''重要日期 IMPORTANT DATES'''

4月月1日报名开始
6月1日报名截至

==大会主题Topics==

6月14日-15日将是面向DBA入门培训的课程。 6月16日-17日是大会的演讲，大会安排在三个分会场举行，来自国内外的专家将会就PostgreSQL的话题进行演讲，演讲的主要主题如下：
*系统使用PostgreSQL的架构(包括HA，集群，灾备等)
*PostgreSQL的监控、配置、各种辅助工具
*各种数据库向PostgreSQL的迁移
*使用PostgreSQL的数据分析、数据仓库仓库
*性能调优、性能基线测试
*PostgreSQL的分区
*集群，复制
*实际的应用案例
*使用PostgreSQL的地理信息系统
*利用SSD等新技术提高PostgreSQL的性能
*PostgreSQL 9.2的新功能
*PostgreSQL的新特性的开发、中文相关的全文检索等
*PostgreSQL的内核分析，研究，以及教学上的应用

A Two-day free Postgres DBA training will be given for people who want to learn PostgreSQL administration in the first two days. In 16-17 June, and the conference will be organized in three tracks, PostgreSQL experts from local and community will give talks about:
*System architecture for using PostgreSQL
*Migration of production systems from another database
*Data warehousing
*Tuning PostgreSQL for different work loads
*Replication and clustering
*Benchmarking and performance engineering
*Case studies
*Location-aware and mapping software with PostGIS
*PostgreSQL 9.2 features
*Research and teaching with PostgreSQL
Community major developers: Simmon Riggs, Suzuki Koichi will give talks about 9.2 features, PG-XC and clustering solutions.

==Postgres集群研讨会 Postgres Clustering Summit ==

*PG-XC专题会议 6.14日下午(仅限于相关公司或者个人)，讨论如何参与到PG-XC的开发等议题。

== 大会议程 Schedule (subject to change) ==
===基础培训专场 Basic Training===

*6月14日(周四) 9:00-17:00
**PostgresQL 核心架构基础(Process/Storage/Momery等)
**PostgresQL 安装及文件结构
**PostgresQL 配置基础
**PostgresQL 数据库逻辑结构(Database/Schema/Tablespace等)
**PostgresQL 数据备份及恢复
**PostgresQL 数据库权限及安全管理
*6月15日(周五) 9:00 – 17:00
**PostgresQL 基于时间点的数据恢复(Point-in Time Recovery)
**PostgresQL 运行时维护管理(MVCC/Vacuum/Reindex等)
**PostgresQL 存储过程及调试(pg/plsql，pgAdminIII Debuger)
**PostgresQL 监控排错基础
**PostgreSQL优化培训

*以下内容只进行简要概念介绍(Day2)：
**数据库集群概论
**PostgresQL Hot-Standby and Stream Replication简介
**PostgresQL 高可用性集群架构简介
**PostgresQL PGPool 读写分离架构简介
**PostgresQL 集中管理及性能优化基础

===大会 Conference===

*第一天： 6月16日(周六)

====主场1 ====
**会场主持:李元佳
**9:00-9：05大会介绍
**9:05-9:15大会致辞
**9:15-10:00 主题演讲1 Magnus Hagander，PostgreSQL 9.2 features and Roadmap
**10:00-10:45 主题演讲1-1 Suzuki Koichi, Postgres-XC, Read/Write scalable PostgreSQL cluster
**10:45-11:00 主题演讲1-2 Suzuki Koichi, PostgreSQL usage in NTT
**11:00-11:45 主题演讲2 Simon Riggs,
**12:00-12:15 集体照相

==== 分场1 DBA专场 ====
==== 分场2 PG内核开发专场 ====
==== 分场3 应用开发专场 ====

晚餐：18：00

*第二天6月17日(周日)
上午
会场1：
会场2：
会场3：
下午：
讨论、提问

===PG-XC专场 PG XC Summit ===
*时间：6.14日 14:00 - 17:00
*地点：人民大学
*议题：
**PG-XC培训 14:00 - 16:00
**PG-XC讨论 16:00 - 17:00
*参与嘉宾：PG-XC首席架构师铃木幸一 Suzuki Koichi

== 大会演讲 TOPICS ==
*'''主题演讲Keynote: Magnus Hagander，PostgreSQL 9.2的新功能及路线图，PostgreSQL 9.2 features and Roadmap''', 45分钟
*'''主题演讲Keynote: Koichi Suzuki，Postgres-XC读写可扩展的PostgreSQL集群,Postgres-XC, Read/Write scalable PostgreSQL cluster''', 45分钟
:Postgres-XC is PostgreSQL-based database cluster based upon shared-nothing configuration. Postgres-XC (simply XC) provides both read and write scalability. XC's servers are symmetric so that applications can connect any of the servers. With more servers, you can get more performance. No dedicated hardware is required. You need only a commodity hardware. Each server provides single global database view. Complete transaction management features are provided just as single PostgreSQL.

:The talk will cover the motivation, architecture, performance of XC, as well as high-availability features, milestone and how to be a part of XC community. Architecture will be covered how how to provide full-fledged transaction property and both read/write scalability, as well as distributed query processing. High-availability feature will cover how to backup each server and components for integration.
*'''主题演讲Keynote: Simon Riggs，企业级的PostgreSQL及未来的发展方向 Enterprise PostgreSQL & Futures''', 45分钟
*'''主题演讲Talks: Simon Rigg，PostgreSQL流复制及未来的发展方向 PostgreSQL Replication & Futures''', 45分钟

*'''专家圆桌讨论Panel Discussion:Magnus, Simon, 彭智勇， 1小时

*'''演讲Talks:何伟平 He Weiping(Laser)， 45小时
*'''演讲Talks: DBA管理,Koichi Suzuki，PostgreSQL在电信市场的应用, PostgreSQL use in telecommunication market (NTT group)'''，15分钟
*'''演讲Talks: DBA管理,萧少聪 Scott xiu，PostgreSQL的流复制'''，45分钟
*'''演讲Talks: DBA管理,唐诚(阿里巴巴) Tang Cheng(Alibaba),greenplum数据库经验谈'''，45分钟
:1. greenplum的架构简介 2. greenplum 与　hadoop的对比 3. greenplum 的执行计划 4. 日常维护经验谈

*'''演讲: DBA管理,德哥(斯凯网络) Digoal(Skymobi)，PostgreSQL 杂谈'''，45分钟
*'''演讲: DBA管理,Francs(斯凯网络),Francs(Skymobi)，PostgreSQL vs Oracle'''，45分钟
*'''DBA 圆桌讨论 Panel Discussion:

*'''演讲: 应用开发,(去哪儿)， '''，45分钟
*'''演讲: 应用开发,， PostGIS 应用'''，45分钟
*'''演讲: 应用开发,Gavin Yang(VMWARE)， PostgreSQL的数据分析工具MADlib, In-Database Analytics with MADlib'''，45分钟
:MADlib is an open-source library on RDBMS for scalable in-database big data analytics. It provides data-parallel implementations of mathematical, statistical and machine learning methods for structured and unstructured data. This talk introduces some of the problems we are tackling in the MADlib initiative and the solutions for them. We will also talk about our recent work in building decision trees and random forests within databases.
*'''演讲: 应用开发,蔡红雨(高鹏)，'''，45分钟
*'''应用开发圆桌讨论: 1小时

*'''演讲：内核开发,Magnus Hagander，Involving in PostgreSQL Development'''，45分钟
*'''演讲: 内核开发,彭智勇，PostgreSQL 内核简介'''，45分钟
*'''演讲: 内核开发,张孝(中国人民大学)，《高校数据库教学中PostgreSQL的学习、使用与定制》简介'''，45分钟
:本报告主要报告在高校的数据库教学中如何利用PostgreSQL这样的开源数据库系统来了帮助学生切实从“白盒”角度感受一个大型数据库管理系统并深化有关数据库相关理论的学习与认知。报告将从入门级入手介绍如何由外及内地学习和了解PostgreSQL的基本特点并进行系统从无到有的建立。进一步来介绍如何使用PostgreSQL来满足教学(比如数据库概论)的一些课程要求以及对某些数据库应用的支持。此外，还会根据教学中一些高级内容(比如针对研究生的《数据库原理与实现》的要求)介绍如何对PostgreSQL进行内核级的改造以提供新的系统特性或功能增强。
*'''演讲: 内核开发,Cao Yu(EMC),Multi-Instance Aware Query Processing'''，45分钟
:It is not uncommon for analytical database queries to contain multiple instances of the same (base or derived) relation. Unfortunately, almost all of the conventional relational query processing techniques are oblivious to these instances and instead deal with them as independent relations. As a result, the query evaluation performance would be suboptimal. This talk will describe our research on the problem of optimizing complex queries with multiple relational instances, which surprisingly has never received systematic or specialized public studies in the past. We investigate three fundamental query execution operations, i.e. table scan, table sorting and table join, to exploit the corresponding optimization opportunities when these operations involve multiple instances.

:First, we present a light-weight multi-instance-aware plan evaluation engine that enables multiple instances of a relation to share one physical table scan. Second, we develop a sort-sharing-aware query processing framework to maximize the effects of sharing and collaboration during achieving different sorting requirements for multiple instances. Third, we propose an efficient algorithm for performing self-join operations between two instances and with join predicates involving two distinct instances. In all the above works, we validate our techniques by integrating them into PostgreSQL and testing their effectiveness using TPC benchmarks.
*'''演讲: 内核开发,孙鹏,'''，45分钟
*'''内核开发圆桌讨论: 1小时

*'''演讲: 李元佳,PostgreSQL用户会介绍'''，30分钟
*'''颁奖礼''' 30分钟

== 大会演讲嘉宾 SPEAKERS ==
* '''[http://www.hagander.net/ Magnus Hagander]'''
:Core Team Member and Major Developer of PostgreSQL Global Development Group
:Conference organizer at PostgreSQL Conference Europe
:Principal Database Consultant and Open Source Expert at Redpill Linpro
:President of the Board at PostgreSQL Europe

*'''[http://www.linkedin.com/profile/view?id=16308658&locale=en_US&trk=tyah Simon Riggs]'''

:Major Developer & Committer at PostgreSQL Global Development Group and CTO and Database Architect at 2ndQuadrant.
:Professional developer and consultant for PostgreSQL, following on from 20 years of experience with a variety of database technologies. Regular conference speaker.
:Enterprise-level experience working from within startup businesses product/service companies, including 2 successful IPOs.

*'''[http://www.intellilink.co.jp/plan/corporate/fellow_OSS-DB.html 铃木幸一Suzuki Koichi]'''

:Fellow at NTT DATA Intellilink Corporation

:After joining NTT Laboratory, Koichi Suzuki was involved in the following R&D activities:
::Extended Unix Code (EUC) development and Unicode standardization,
::Oracle port to NTT's proprietary Unix workstations,
::Object-Relation Databae Management System development (UniSQL), and
::PostgreSQL and Postgres-XC development.
::From 1991 to 1993, he was a guest researcher in MIT.

: 
:[http://sourceforge.jp/projects/nttdatagroup-oss-square/wiki/koichi_suzuki Official web page](in Japanese) 
:[http://postgres-xc.sourceforge.net/ Postgres-XC]

*'''彭智勇 Peng zhiyong'''

:日本京都大学工学博士，武汉大学计算机学院副院长、教授、博士生导师，中国计算机协会数据库专业委员会委员，国家信息产业部数据库标准工作组成员，武汉市电子政务宽带网络平台软件系统总体设计专家组成员，国内外许多学术会议程序委员会的委员。1985年毕业于武汉大学计算机科学系，获理学学士学位。1988年毕业于国防科技大学计算机系，获工学硕士学位。1995年毕业于日本京都大学信息科学系, 获工学博士学位。1995－1997年在日本京都高度技术研究所工作，研究员。1997－2000年在美国惠普公司的研究所工作，研究员。2001-2002年在武汉大学计算机科学与技术博士后流动站从事博士后研究工作。

*'''张孝 Zhang Xiao'''

:中国人民大学信息学院副教授，中科院计算所博士，中国人民大学硕士及学士，师从中国著名数据库专家王珊教授。

:1997年以访问学者的身份在香港中文大学系统工程与工程管理系从事合作研究与开发。2006年在印第安纳大学DSI&DDE实验室作为访问学者进行e-Science相关的元数据管理和数据出处领域访问研究。
:主要研究领域包括：并行数据库系统、分布式数据库系统、移动数据库等。尤其擅长大型数据库系统体系的原理分析、设计和实现技术，熟悉开源数据库系统PostgreSQL源代码。近期研究兴趣集中在：数据库体系结构、大规模非结构化与智能视频数据管理、数据库关键词检索等。
:从1996年以来作为主要技术骨干或核心骨干先后参与多项国家科技攻关项目、国家自然科学基金、北京市重大科技项目及国家863项目。先后获得多项省部级奖励，包括教育部科技进步二等奖1次，北京市科技进步一等奖1次、二等奖2次。独立主持有国家自然科学基金、核高基专项子课题以及国际企业的合作项目等。
:目前是中国计算机学会高级会员和中国计算机学会虚拟现实与可视化专委会委员、ACM协会会员。先后担任APWEB 2011本地主席、国际研讨会WAIM/USD'2012 和国际研讨会APWeb/WAIM DBIR09程序委员会联合主席以及NDBC 2010 Demo主席等学术兼职。先后在《软件学报》、《计算机学报》、《计算机研究与发展》等期刊杂志以及ICDE等国际会议上单独或联合发表论文20余篇，参与王珊教授主编的3本著作的编写工作。主要担任《数据结构》、《数据库原理与实现》、《PostgreSQL源代码阅读与分析》等课程的教学工作。

*何伟平

*唐诚(阿里巴巴)
:阿里巴巴公司数据库专家，精通greenplum和PostgreSQL数据库，为公司这一技术领域的带头人。也精通oracle数据库和AIX小型机，精通C/C++编程。
*德哥(斯凯网络)
:斯凯网络DBA主管，多年数据库平台工作经验,熟悉Oracle,PostgreSQL,EnterpriseDB,GreenPlum,mongoDB等多种数据库平台,熟悉OS,存储等.负责斯凯网络数据库架构设计,性能调优与维护,存储系统设计与维护,OS维护等工作.
:Digoal is the cheif DBA in Sky-mobi which runs the largest mobile app market in China, he manages a system consisting of over 300 PostgreSQL nodes, he will share us with his experience in managing PostgreSQL.
*Francs(斯凯网络)
*Gavin Yang(VMWARE)
*Cao Yu(EMC)
:Yu is currently working at EMC Labs China as a senior research scientist, after receiving his Ph.D. from National University of Singapore. His broad research interest lies in large-scale data management. More specifically, he does system-oriented research on database query processing and optimization, massive data storage and MapReduce-based big data analytics. He has published papers on top venues like SIGMOD, ICDE, EDBT, VLDB Journal, etc.
*萧少聪，
:曾任职于广东省Linux技术服务中心及红帽中国区唯一总代理，担任开源架构讲师及负责Red Hat系统开源产品华南地区技术顾问及架构设计工作。06年通过红帽RHCE认证，并获得红帽RHCI认证讲师资格，09年通过红帽全球最高认证 RHCA，成为国内前20名考取此认证的架构师。2012年成为EnterpriseDB公司在大中华区首位官方认证的 Postgres数据库讲师，同年协助李元佳等人筹建PostgresQL中国用户组。现任北京神州立诚科技有限公司技术总监，拥有多年开发、网络架构设计及项目管理经验，专注于开源Linux系统管理及Postgres数据库、优化、集群系统、云-虚拟架构设计领域。

*''孙鹏''
:中国科学院计算技术研究所工学博士，美国北德克萨斯大学访问学者，现任中国科学院软件研究所综合信息系统技术国家级重点实验室助理研究员，研究方向为空间数据库和空间数据库挖掘。
*李元佳,

== 大会预算 Budget==

我们在征集大会的赞助商，请赞助我们的大会，帮助我们大会顺利举行。
We are recruiting sponsors for the conference to help us hold this conference.

*预算约11万 Spending 110,000 RMB
**外宾旅费费用6万 Travel funding for foreign speakers 60,000 RMB （机票加酒店及车辆接送等每人约2万， 3 Guestes, each is about 20,000 ）
**大会场地 Conference Room 41,920 RMB（两天会议厅，加2天培训及3个分会场教室，另加投影仪等费用）
**用户礼品 Attendee Gift 6,000 RMB（T恤200件x30)
**购物袋胸卡 Bag 3,000 RMB (200本x15元)

*收入约11万 Income 110,000 RMB
**赞助 Sponsor 50,000RMB
**门票 Ticket 60,000RMB (300x200元=6万）

== 参与我们 Participate ==

''演讲者''

欢迎在PostgreSQL的企业应用、架构设计、运维管理、应用开发等方面有心得的朋友，发表演讲。如果你有需要发表的内容，请联系 galylee@gmail.com

''志愿者''

请帮助我们宣传大会，在你的网站，或者在论坛，或者在其他大会，告诉大家PG全国大会的举行信息。

''赞助''

我们是非盈利的组织，单单凭我们的力量无法承担大会的会场等相关的运营费用，只有相关企业的赞助和参与才有可能有必要的资源在国内培养PostgreSQL社区的形成。更多的赞助，可以让我们能邀请到更重量级的嘉宾为我们演讲，可以让我们有个交流和参与的平台。需要赞助的包括：场地费用及宣传品、邀请国外嘉宾的机票及食宿、嘉宾的演讲资料印刷、各种小礼物、大会首日晚上的酒会等等。。

''捐赠''

我们是旨在推广PG在中国发展的非营利的团体，欢迎企业为PG社区进行捐赠，捐赠的款项将完全用于PG社区的推广，包括官方文档的翻译、社区网站的托管、PG的技术交流会、PG大会的运营等。

[http://wiki.postgresql.org/wiki/Pgconfchina2012-admin 大会组织]

[[Category:PostgreSQL Events]]

Pgconfchina2012

2012-05-07T21:19:37Z

Dfetter: /* 主场1 */

== PostgreSQL Conference China 2012 ==

PostgreSQL中国用户会全国大会是由PostgreSQL中国用户会(CPUG)主办的旨在促进PostgreSQL在中国发展的非营利性的会议年度大会，大会是分享PostgreSQL的最佳使用实践、学习最新的功能特性、结交本领域的朋友的最佳场所。

2012年度大会将于2012年6月14日-17日在北京举行，中国人民大学信息学院承办。其中6月14日-15日是面向初级人员的入门培训，6月16(周六),17(周日)日是正式大会。本次大会将邀请到社区的核心组员Magnus Hagander,主要开发人员Simon Rigg、PG-XC的首席架构师铃木幸一(Suzuki Koichi)及其他海外专家为本次大会分享最前沿的PostgreSQL方面的信息，同时还有业界的资深人员作相关演讲。

PostgresQL User Group Conference China which organized by CPUG(China Postgres User Group) is an annual conference for PostgreSQL users in China, the conference is a hub for learning new features, sharing the know-how, and making friends about PostgreSQL.

PostgresQL User Group Conference China 2012 will be on 14-17 June 2012 at Renmin University of China in Beijing with two days of Tutorials on 14-15 June 2012. Magnus Hagander,Simon Rigg and Suzuki Koichi from community will also join this conference to give keynote speachs.

== 信息 Information ==

'''日期 DATE''': June 14-17, 2012

'''地点 LOCATION''': 中国人民大学 Remin University of China, Beijing，China

'''地址 ADDRESS''':

'''主办 Endorsed by''': CPUG(China PostgreSQL User Group) 中国PostgreSQL用户会

'''承办 Organizer''': 中国人民大学信息学院

'''协办''': IT168盛拓传媒

'''赞助支持伙伴 SPONSORS''':

'''内容 TOPIC''': PostgreSQL的企业应用、架构设计、运维管理、应用开发

'''费用 FEE''': 公司名义：300RMB(由于大会目前缺乏赞助商，所以需要门票收费，解决资金不足问题, 具体预算见下面),个人名义：200RMB(不提供发票), 学生100RMB(需提供学生证,不提供发票)。

'''缴费方法 ''':
银行
开户人
账号：

注1：如需开发票，请发邮件联系 galylee at gmail.com
注2：本次缴费由PG中国用户会负责，与IT168无任何关系，如产生任何纠纷由PG中国用户会负责，有问题请直接联系李元佳 Galylee at gmail.com 13710389225。

'''餐费 Lunch FEE''' 自助餐 120元/人(两天) 如需预定请注明

'''其他赞助商'''

'''参加方法 REGISTRATION''':
：本届大会将由IT168负责本次大会的报名活动，届时请参考相关主页。

'''联系方式 CONTACT''':

如有任何疑问欢迎联系。
Please contact if you have any questions.
大会会务负责人 Conference Orginizer：李元佳 Galy Lee
手机 Mobile：+86-13710389225
邮件 Email：galylee at gmail.com

'''重要日期 IMPORTANT DATES'''

4月月1日报名开始
6月1日报名截至

==大会主题Topics==

6月14日-15日将是面向DBA入门培训的课程。 6月16日-17日是大会的演讲，大会安排在三个分会场举行，来自国内外的专家将会就PostgreSQL的话题进行演讲，演讲的主要主题如下：
*系统使用PostgreSQL的架构(包括HA，集群，灾备等)
*PostgreSQL的监控、配置、各种辅助工具
*各种数据库向PostgreSQL的迁移
*使用PostgreSQL的数据分析、数据仓库仓库
*性能调优、性能基线测试
*PostgreSQL的分区
*集群，复制
*实际的应用案例
*使用PostgreSQL的地理信息系统
*利用SSD等新技术提高PostgreSQL的性能
*PostgreSQL 9.2的新功能
*PostgreSQL的新特性的开发、中文相关的全文检索等
*PostgreSQL的内核分析，研究，以及教学上的应用

A Two-day free Postgres DBA training will be given for people who want to learn PostgreSQL administration in the first two days. In 16-17 June, and the conference will be organized in three tracks, PostgreSQL experts from local and community will give talks about:
*System architecture for using PostgreSQL
*Migration of production systems from another database
*Data warehousing
*Tuning PostgreSQL for different work loads
*Replication and clustering
*Benchmarking and performance engineering
*Case studies
*Location-aware and mapping software with PostGIS
*PostgreSQL 9.2 features
*Research and teaching with PostgreSQL
Community major developers: Simmon Rigg, Suzuki Koichi will give talks about 9.2 features, PG-XC and clustering solutions.

==Postgres集群研讨会 Postgres Clustering Summit ==

*PG-XC专题会议 6.14日下午(仅限于相关公司或者个人)，讨论如何参与到PG-XC的开发等议题。

== 大会议程 Schedule (subject to change) ==
===基础培训专场 Basic Training===

*6月14日(周四) 9:00-17:00
**PostgresQL 核心架构基础(Process/Storage/Momery等)
**PostgresQL 安装及文件结构
**PostgresQL 配置基础
**PostgresQL 数据库逻辑结构(Database/Schema/Tablespace等)
**PostgresQL 数据备份及恢复
**PostgresQL 数据库权限及安全管理
*6月15日(周五) 9:00 – 17:00
**PostgresQL 基于时间点的数据恢复(Point-in Time Recovery)
**PostgresQL 运行时维护管理(MVCC/Vacuum/Reindex等)
**PostgresQL 存储过程及调试(pg/plsql，pgAdminIII Debuger)
**PostgresQL 监控排错基础
**PostgreSQL优化培训

*以下内容只进行简要概念介绍(Day2)：
**数据库集群概论
**PostgresQL Hot-Standby and Stream Replication简介
**PostgresQL 高可用性集群架构简介
**PostgresQL PGPool 读写分离架构简介
**PostgresQL 集中管理及性能优化基础

===大会 Conference===

*第一天： 6月16日(周六)

====主场1 ====
**会场主持:李元佳
**9:00-9：05大会介绍
**9:05-9:15大会致辞
**9:15-10:00 主题演讲1 Magnus Hagander，PostgreSQL 9.2 features and Roadmap
**10:00-10:45 主题演讲1-1 Suzuki Koichi, Postgres-XC, Read/Write scalable PostgreSQL cluster
**10:45-11:00 主题演讲1-2 Suzuki Koichi, PostgreSQL usage in NTT
**11:00-11:45 主题演讲2 Simon Riggs,
**12:00-12:15 集体照相

==== 分场1 DBA专场 ====
==== 分场2 PG内核开发专场 ====
==== 分场3 应用开发专场 ====

晚餐：18：00

*第二天6月17日(周日)
上午
会场1：
会场2：
会场3：
下午：
讨论、提问

===PG-XC专场 PG XC Summit ===
*时间：6.14日 14:00 - 17:00
*地点：人民大学
*议题：
**PG-XC培训 14:00 - 16:00
**PG-XC讨论 16:00 - 17:00
*参与嘉宾：PG-XC首席架构师铃木幸一 Suzuki Koichi

== 大会演讲 TOPICS ==
*'''主题演讲Keynote: Magnus Hagander，PostgreSQL 9.2的新功能及路线图，PostgreSQL 9.2 features and Roadmap''', 45分钟
*'''主题演讲Keynote: Koichi Suzuki，Postgres-XC读写可扩展的PostgreSQL集群,Postgres-XC, Read/Write scalable PostgreSQL cluster''', 45分钟
:Postgres-XC is PostgreSQL-based database cluster based upon shared-nothing configuration. Postgres-XC (simply XC) provides both read and write scalability. XC's servers are symmetric so that applications can connect any of the servers. With more servers, you can get more performance. No dedicated hardware is required. You need only a commodity hardware. Each server provides single global database view. Complete transaction management features are provided just as single PostgreSQL.

:The talk will cover the motivation, architecture, performance of XC, as well as high-availability features, milestone and how to be a part of XC community. Architecture will be covered how how to provide full-fledged transaction property and both read/write scalability, as well as distributed query processing. High-availability feature will cover how to backup each server and components for integration.
*'''主题演讲Keynote: Simon Rigg，企业级的PostgreSQL及未来的发展方向 Enterprise PostgreSQL & Futures''', 45分钟
*'''主题演讲Talks: Simon Rigg，PostgreSQL流复制及未来的发展方向 PostgreSQL Replication & Futures''', 45分钟

*'''专家圆桌讨论Panel Discussion:Magnus, Simon, 彭智勇， 1小时

*'''演讲Talks:何伟平 He Weiping(Laser)， 45小时
*'''演讲Talks: DBA管理,Koichi Suzuki，PostgreSQL在电信市场的应用, PostgreSQL use in telecommunication market (NTT group)'''，15分钟
*'''演讲Talks: DBA管理,萧少聪 Scott xiu，PostgreSQL的流复制'''，45分钟
*'''演讲Talks: DBA管理,唐诚(阿里巴巴) Tang Cheng(Alibaba),greenplum数据库经验谈'''，45分钟
:1. greenplum的架构简介 2. greenplum 与　hadoop的对比 3. greenplum 的执行计划 4. 日常维护经验谈

*'''演讲: DBA管理,德哥(斯凯网络) Digoal(Skymobi)，PostgreSQL 杂谈'''，45分钟
*'''演讲: DBA管理,Francs(斯凯网络),Francs(Skymobi)，PostgreSQL vs Oracle'''，45分钟
*'''DBA 圆桌讨论 Panel Discussion:

*'''演讲: 应用开发,(去哪儿)， '''，45分钟
*'''演讲: 应用开发,， PostGIS 应用'''，45分钟
*'''演讲: 应用开发,Gavin Yang(VMWARE)， PostgreSQL的数据分析工具MADlib, In-Database Analytics with MADlib'''，45分钟
:MADlib is an open-source library on RDBMS for scalable in-database big data analytics. It provides data-parallel implementations of mathematical, statistical and machine learning methods for structured and unstructured data. This talk introduces some of the problems we are tackling in the MADlib initiative and the solutions for them. We will also talk about our recent work in building decision trees and random forests within databases.
*'''演讲: 应用开发,蔡红雨(高鹏)，'''，45分钟
*'''应用开发圆桌讨论: 1小时

*'''演讲：内核开发,Magnus Hagander，Involving in PostgreSQL Development'''，45分钟
*'''演讲: 内核开发,彭智勇，PostgreSQL 内核简介'''，45分钟
*'''演讲: 内核开发,张孝(中国人民大学)，《高校数据库教学中PostgreSQL的学习、使用与定制》简介'''，45分钟
:本报告主要报告在高校的数据库教学中如何利用PostgreSQL这样的开源数据库系统来了帮助学生切实从“白盒”角度感受一个大型数据库管理系统并深化有关数据库相关理论的学习与认知。报告将从入门级入手介绍如何由外及内地学习和了解PostgreSQL的基本特点并进行系统从无到有的建立。进一步来介绍如何使用PostgreSQL来满足教学(比如数据库概论)的一些课程要求以及对某些数据库应用的支持。此外，还会根据教学中一些高级内容(比如针对研究生的《数据库原理与实现》的要求)介绍如何对PostgreSQL进行内核级的改造以提供新的系统特性或功能增强。
*'''演讲: 内核开发,Cao Yu(EMC),Multi-Instance Aware Query Processing'''，45分钟
:It is not uncommon for analytical database queries to contain multiple instances of the same (base or derived) relation. Unfortunately, almost all of the conventional relational query processing techniques are oblivious to these instances and instead deal with them as independent relations. As a result, the query evaluation performance would be suboptimal. This talk will describe our research on the problem of optimizing complex queries with multiple relational instances, which surprisingly has never received systematic or specialized public studies in the past. We investigate three fundamental query execution operations, i.e. table scan, table sorting and table join, to exploit the corresponding optimization opportunities when these operations involve multiple instances.

:First, we present a light-weight multi-instance-aware plan evaluation engine that enables multiple instances of a relation to share one physical table scan. Second, we develop a sort-sharing-aware query processing framework to maximize the effects of sharing and collaboration during achieving different sorting requirements for multiple instances. Third, we propose an efficient algorithm for performing self-join operations between two instances and with join predicates involving two distinct instances. In all the above works, we validate our techniques by integrating them into PostgreSQL and testing their effectiveness using TPC benchmarks.
*'''演讲: 内核开发,孙鹏,'''，45分钟
*'''内核开发圆桌讨论: 1小时

*'''演讲: 李元佳,PostgreSQL用户会介绍'''，30分钟
*'''颁奖礼''' 30分钟

== 大会演讲嘉宾 SPEAKERS ==
* '''[http://www.hagander.net/ Magnus Hagander]'''
:Core Team Member and Major Developer of PostgreSQL Global Development Group
:Conference organizer at PostgreSQL Conference Europe
:Principal Database Consultant and Open Source Expert at Redpill Linpro
:President of the Board at PostgreSQL Europe

*'''[http://www.linkedin.com/profile/view?id=16308658&locale=en_US&trk=tyah Simon Riggs]'''

:Major Developer & Committer at PostgreSQL Global Development Group and CTO and Database Architect at 2ndQuadrant.
:Professional developer and consultant for PostgreSQL, following on from 20 years of experience with a variety of database technologies. Regular conference speaker.
:Enterprise-level experience working from within startup businesses product/service companies, including 2 successful IPOs.

*'''[http://www.intellilink.co.jp/plan/corporate/fellow_OSS-DB.html 铃木幸一Suzuki Koichi]'''

:Fellow at NTT DATA Intellilink Corporation

:After joining NTT Laboratory, Koichi Suzuki was involved in the following R&D activities:
::Extended Unix Code (EUC) development and Unicode standardization,
::Oracle port to NTT's proprietary Unix workstations,
::Object-Relation Databae Management System development (UniSQL), and
::PostgreSQL and Postgres-XC development.
::From 1991 to 1993, he was a guest researcher in MIT.

: 
:[http://sourceforge.jp/projects/nttdatagroup-oss-square/wiki/koichi_suzuki Official web page](in Japanese) 
:[http://postgres-xc.sourceforge.net/ Postgres-XC]

*'''彭智勇 Peng zhiyong'''

:日本京都大学工学博士，武汉大学计算机学院副院长、教授、博士生导师，中国计算机协会数据库专业委员会委员，国家信息产业部数据库标准工作组成员，武汉市电子政务宽带网络平台软件系统总体设计专家组成员，国内外许多学术会议程序委员会的委员。1985年毕业于武汉大学计算机科学系，获理学学士学位。1988年毕业于国防科技大学计算机系，获工学硕士学位。1995年毕业于日本京都大学信息科学系, 获工学博士学位。1995－1997年在日本京都高度技术研究所工作，研究员。1997－2000年在美国惠普公司的研究所工作，研究员。2001-2002年在武汉大学计算机科学与技术博士后流动站从事博士后研究工作。

*'''张孝 Zhang Xiao'''

:中国人民大学信息学院副教授，中科院计算所博士，中国人民大学硕士及学士，师从中国著名数据库专家王珊教授。

:1997年以访问学者的身份在香港中文大学系统工程与工程管理系从事合作研究与开发。2006年在印第安纳大学DSI&DDE实验室作为访问学者进行e-Science相关的元数据管理和数据出处领域访问研究。
:主要研究领域包括：并行数据库系统、分布式数据库系统、移动数据库等。尤其擅长大型数据库系统体系的原理分析、设计和实现技术，熟悉开源数据库系统PostgreSQL源代码。近期研究兴趣集中在：数据库体系结构、大规模非结构化与智能视频数据管理、数据库关键词检索等。
:从1996年以来作为主要技术骨干或核心骨干先后参与多项国家科技攻关项目、国家自然科学基金、北京市重大科技项目及国家863项目。先后获得多项省部级奖励，包括教育部科技进步二等奖1次，北京市科技进步一等奖1次、二等奖2次。独立主持有国家自然科学基金、核高基专项子课题以及国际企业的合作项目等。
:目前是中国计算机学会高级会员和中国计算机学会虚拟现实与可视化专委会委员、ACM协会会员。先后担任APWEB 2011本地主席、国际研讨会WAIM/USD'2012 和国际研讨会APWeb/WAIM DBIR09程序委员会联合主席以及NDBC 2010 Demo主席等学术兼职。先后在《软件学报》、《计算机学报》、《计算机研究与发展》等期刊杂志以及ICDE等国际会议上单独或联合发表论文20余篇，参与王珊教授主编的3本著作的编写工作。主要担任《数据结构》、《数据库原理与实现》、《PostgreSQL源代码阅读与分析》等课程的教学工作。

*何伟平

*唐诚(阿里巴巴)
:阿里巴巴公司数据库专家，精通greenplum和PostgreSQL数据库，为公司这一技术领域的带头人。也精通oracle数据库和AIX小型机，精通C/C++编程。
*德哥(斯凯网络)
:斯凯网络DBA主管，多年数据库平台工作经验,熟悉Oracle,PostgreSQL,EnterpriseDB,GreenPlum,mongoDB等多种数据库平台,熟悉OS,存储等.负责斯凯网络数据库架构设计,性能调优与维护,存储系统设计与维护,OS维护等工作.
:Digoal is the cheif DBA in Sky-mobi which runs the largest mobile app market in China, he manages a system consisting of over 300 PostgreSQL nodes, he will share us with his experience in managing PostgreSQL.
*Francs(斯凯网络)
*Gavin Yang(VMWARE)
*Cao Yu(EMC)
:Yu is currently working at EMC Labs China as a senior research scientist, after receiving his Ph.D. from National University of Singapore. His broad research interest lies in large-scale data management. More specifically, he does system-oriented research on database query processing and optimization, massive data storage and MapReduce-based big data analytics. He has published papers on top venues like SIGMOD, ICDE, EDBT, VLDB Journal, etc.
*萧少聪，
:曾任职于广东省Linux技术服务中心及红帽中国区唯一总代理，担任开源架构讲师及负责Red Hat系统开源产品华南地区技术顾问及架构设计工作。06年通过红帽RHCE认证，并获得红帽RHCI认证讲师资格，09年通过红帽全球最高认证 RHCA，成为国内前20名考取此认证的架构师。2012年成为EnterpriseDB公司在大中华区首位官方认证的 Postgres数据库讲师，同年协助李元佳等人筹建PostgresQL中国用户组。现任北京神州立诚科技有限公司技术总监，拥有多年开发、网络架构设计及项目管理经验，专注于开源Linux系统管理及Postgres数据库、优化、集群系统、云-虚拟架构设计领域。

*''孙鹏''
:中国科学院计算技术研究所工学博士，美国北德克萨斯大学访问学者，现任中国科学院软件研究所综合信息系统技术国家级重点实验室助理研究员，研究方向为空间数据库和空间数据库挖掘。
*李元佳,

== 大会预算 Budget==

我们在征集大会的赞助商，请赞助我们的大会，帮助我们大会顺利举行。
We are recruiting sponsors for the conference to help us hold this conference.

*预算约11万 Spending 110,000 RMB
**外宾旅费费用6万 Travel funding for foreign speakers 60,000 RMB （机票加酒店及车辆接送等每人约2万， 3 Guestes, each is about 20,000 ）
**大会场地 Conference Room 41,920 RMB（两天会议厅，加2天培训及3个分会场教室，另加投影仪等费用）
**用户礼品 Attendee Gift 6,000 RMB（T恤200件x30)
**购物袋胸卡 Bag 3,000 RMB (200本x15元)

*收入约11万 Income 110,000 RMB
**赞助 Sponsor 50,000RMB
**门票 Ticket 60,000RMB (300x200元=6万）

== 参与我们 Participate ==

''演讲者''

欢迎在PostgreSQL的企业应用、架构设计、运维管理、应用开发等方面有心得的朋友，发表演讲。如果你有需要发表的内容，请联系 galylee@gmail.com

''志愿者''

请帮助我们宣传大会，在你的网站，或者在论坛，或者在其他大会，告诉大家PG全国大会的举行信息。

''赞助''

我们是非盈利的组织，单单凭我们的力量无法承担大会的会场等相关的运营费用，只有相关企业的赞助和参与才有可能有必要的资源在国内培养PostgreSQL社区的形成。更多的赞助，可以让我们能邀请到更重量级的嘉宾为我们演讲，可以让我们有个交流和参与的平台。需要赞助的包括：场地费用及宣传品、邀请国外嘉宾的机票及食宿、嘉宾的演讲资料印刷、各种小礼物、大会首日晚上的酒会等等。。

''捐赠''

我们是旨在推广PG在中国发展的非营利的团体，欢迎企业为PG社区进行捐赠，捐赠的款项将完全用于PG社区的推广，包括官方文档的翻译、社区网站的托管、PG的技术交流会、PG大会的运营等。

[http://wiki.postgresql.org/wiki/Pgconfchina2012-admin 大会组织]

[[Category:PostgreSQL Events]]

Pgconfchina2012

2012-05-07T21:19:22Z

Dfetter: /* 基础培训专场 Basic Training */

== PostgreSQL Conference China 2012 ==

PostgreSQL中国用户会全国大会是由PostgreSQL中国用户会(CPUG)主办的旨在促进PostgreSQL在中国发展的非营利性的会议年度大会，大会是分享PostgreSQL的最佳使用实践、学习最新的功能特性、结交本领域的朋友的最佳场所。

2012年度大会将于2012年6月14日-17日在北京举行，中国人民大学信息学院承办。其中6月14日-15日是面向初级人员的入门培训，6月16(周六),17(周日)日是正式大会。本次大会将邀请到社区的核心组员Magnus Hagander,主要开发人员Simon Rigg、PG-XC的首席架构师铃木幸一(Suzuki Koichi)及其他海外专家为本次大会分享最前沿的PostgreSQL方面的信息，同时还有业界的资深人员作相关演讲。

PostgresQL User Group Conference China which organized by CPUG(China Postgres User Group) is an annual conference for PostgreSQL users in China, the conference is a hub for learning new features, sharing the know-how, and making friends about PostgreSQL.

PostgresQL User Group Conference China 2012 will be on 14-17 June 2012 at Renmin University of China in Beijing with two days of Tutorials on 14-15 June 2012. Magnus Hagander,Simon Rigg and Suzuki Koichi from community will also join this conference to give keynote speachs.

== 信息 Information ==

'''日期 DATE''': June 14-17, 2012

'''地点 LOCATION''': 中国人民大学 Remin University of China, Beijing，China

'''地址 ADDRESS''':

'''主办 Endorsed by''': CPUG(China PostgreSQL User Group) 中国PostgreSQL用户会

'''承办 Organizer''': 中国人民大学信息学院

'''协办''': IT168盛拓传媒

'''赞助支持伙伴 SPONSORS''':

'''内容 TOPIC''': PostgreSQL的企业应用、架构设计、运维管理、应用开发

'''费用 FEE''': 公司名义：300RMB(由于大会目前缺乏赞助商，所以需要门票收费，解决资金不足问题, 具体预算见下面),个人名义：200RMB(不提供发票), 学生100RMB(需提供学生证,不提供发票)。

'''缴费方法 ''':
银行
开户人
账号：

注1：如需开发票，请发邮件联系 galylee at gmail.com
注2：本次缴费由PG中国用户会负责，与IT168无任何关系，如产生任何纠纷由PG中国用户会负责，有问题请直接联系李元佳 Galylee at gmail.com 13710389225。

'''餐费 Lunch FEE''' 自助餐 120元/人(两天) 如需预定请注明

'''其他赞助商'''

'''参加方法 REGISTRATION''':
：本届大会将由IT168负责本次大会的报名活动，届时请参考相关主页。

'''联系方式 CONTACT''':

如有任何疑问欢迎联系。
Please contact if you have any questions.
大会会务负责人 Conference Orginizer：李元佳 Galy Lee
手机 Mobile：+86-13710389225
邮件 Email：galylee at gmail.com

'''重要日期 IMPORTANT DATES'''

4月月1日报名开始
6月1日报名截至

==大会主题Topics==

6月14日-15日将是面向DBA入门培训的课程。 6月16日-17日是大会的演讲，大会安排在三个分会场举行，来自国内外的专家将会就PostgreSQL的话题进行演讲，演讲的主要主题如下：
*系统使用PostgreSQL的架构(包括HA，集群，灾备等)
*PostgreSQL的监控、配置、各种辅助工具
*各种数据库向PostgreSQL的迁移
*使用PostgreSQL的数据分析、数据仓库仓库
*性能调优、性能基线测试
*PostgreSQL的分区
*集群，复制
*实际的应用案例
*使用PostgreSQL的地理信息系统
*利用SSD等新技术提高PostgreSQL的性能
*PostgreSQL 9.2的新功能
*PostgreSQL的新特性的开发、中文相关的全文检索等
*PostgreSQL的内核分析，研究，以及教学上的应用

A Two-day free Postgres DBA training will be given for people who want to learn PostgreSQL administration in the first two days. In 16-17 June, and the conference will be organized in three tracks, PostgreSQL experts from local and community will give talks about:
*System architecture for using PostgreSQL
*Migration of production systems from another database
*Data warehousing
*Tuning PostgreSQL for different work loads
*Replication and clustering
*Benchmarking and performance engineering
*Case studies
*Location-aware and mapping software with PostGIS
*PostgreSQL 9.2 features
*Research and teaching with PostgreSQL
Community major developers: Simmon Rigg, Suzuki Koichi will give talks about 9.2 features, PG-XC and clustering solutions.

==Postgres集群研讨会 Postgres Clustering Summit ==

*PG-XC专题会议 6.14日下午(仅限于相关公司或者个人)，讨论如何参与到PG-XC的开发等议题。

== 大会议程 Schedule (subject to change) ==
===基础培训专场 Basic Training===

*6月14日(周四) 9:00-17:00
**PostgresQL 核心架构基础(Process/Storage/Momery等)
**PostgresQL 安装及文件结构
**PostgresQL 配置基础
**PostgresQL 数据库逻辑结构(Database/Schema/Tablespace等)
**PostgresQL 数据备份及恢复
**PostgresQL 数据库权限及安全管理
*6月15日(周五) 9:00 – 17:00
**PostgresQL 基于时间点的数据恢复(Point-in Time Recovery)
**PostgresQL 运行时维护管理(MVCC/Vacuum/Reindex等)
**PostgresQL 存储过程及调试(pg/plsql，pgAdminIII Debuger)
**PostgresQL 监控排错基础
**PostgreSQL优化培训

*以下内容只进行简要概念介绍(Day2)：
**数据库集群概论
**PostgresQL Hot-Standby and Stream Replication简介
**PostgresQL 高可用性集群架构简介
**PostgresQL PGPool 读写分离架构简介
**PostgresQL 集中管理及性能优化基础

===大会 Conference===

*第一天： 6月16日(周六)

====主场1 ====
**会场主持:李元佳
**9:00-9：05大会介绍
**9:05-9:15大会致辞
**9:15-10:00 主题演讲1 Magnus Hagander，PostgreSQL 9.2 features and Roadmap
**10:00-10:45 主题演讲1-1 Suzuki Koichi, Postgres-XC, Read/Write scalable PostgreSQL cluster
**10:45-11:00 主题演讲1-2 Suzuki Koichi, PostgreSQL usage in NTT
**11:00-11:45 主题演讲2 Simon Rigg,
**12:00-12:15 集体照相

==== 分场1 DBA专场 ====
==== 分场2 PG内核开发专场 ====
==== 分场3 应用开发专场 ====

晚餐：18：00

*第二天6月17日(周日)
上午
会场1：
会场2：
会场3：
下午：
讨论、提问

===PG-XC专场 PG XC Summit ===
*时间：6.14日 14:00 - 17:00
*地点：人民大学
*议题：
**PG-XC培训 14:00 - 16:00
**PG-XC讨论 16:00 - 17:00
*参与嘉宾：PG-XC首席架构师铃木幸一 Suzuki Koichi

== 大会演讲 TOPICS ==
*'''主题演讲Keynote: Magnus Hagander，PostgreSQL 9.2的新功能及路线图，PostgreSQL 9.2 features and Roadmap''', 45分钟
*'''主题演讲Keynote: Koichi Suzuki，Postgres-XC读写可扩展的PostgreSQL集群,Postgres-XC, Read/Write scalable PostgreSQL cluster''', 45分钟
:Postgres-XC is PostgreSQL-based database cluster based upon shared-nothing configuration. Postgres-XC (simply XC) provides both read and write scalability. XC's servers are symmetric so that applications can connect any of the servers. With more servers, you can get more performance. No dedicated hardware is required. You need only a commodity hardware. Each server provides single global database view. Complete transaction management features are provided just as single PostgreSQL.

:The talk will cover the motivation, architecture, performance of XC, as well as high-availability features, milestone and how to be a part of XC community. Architecture will be covered how how to provide full-fledged transaction property and both read/write scalability, as well as distributed query processing. High-availability feature will cover how to backup each server and components for integration.
*'''主题演讲Keynote: Simon Rigg，企业级的PostgreSQL及未来的发展方向 Enterprise PostgreSQL & Futures''', 45分钟
*'''主题演讲Talks: Simon Rigg，PostgreSQL流复制及未来的发展方向 PostgreSQL Replication & Futures''', 45分钟

*'''专家圆桌讨论Panel Discussion:Magnus, Simon, 彭智勇， 1小时

*'''演讲Talks:何伟平 He Weiping(Laser)， 45小时
*'''演讲Talks: DBA管理,Koichi Suzuki，PostgreSQL在电信市场的应用, PostgreSQL use in telecommunication market (NTT group)'''，15分钟
*'''演讲Talks: DBA管理,萧少聪 Scott xiu，PostgreSQL的流复制'''，45分钟
*'''演讲Talks: DBA管理,唐诚(阿里巴巴) Tang Cheng(Alibaba),greenplum数据库经验谈'''，45分钟
:1. greenplum的架构简介 2. greenplum 与　hadoop的对比 3. greenplum 的执行计划 4. 日常维护经验谈

*'''演讲: DBA管理,德哥(斯凯网络) Digoal(Skymobi)，PostgreSQL 杂谈'''，45分钟
*'''演讲: DBA管理,Francs(斯凯网络),Francs(Skymobi)，PostgreSQL vs Oracle'''，45分钟
*'''DBA 圆桌讨论 Panel Discussion:

*'''演讲: 应用开发,(去哪儿)， '''，45分钟
*'''演讲: 应用开发,， PostGIS 应用'''，45分钟
*'''演讲: 应用开发,Gavin Yang(VMWARE)， PostgreSQL的数据分析工具MADlib, In-Database Analytics with MADlib'''，45分钟
:MADlib is an open-source library on RDBMS for scalable in-database big data analytics. It provides data-parallel implementations of mathematical, statistical and machine learning methods for structured and unstructured data. This talk introduces some of the problems we are tackling in the MADlib initiative and the solutions for them. We will also talk about our recent work in building decision trees and random forests within databases.
*'''演讲: 应用开发,蔡红雨(高鹏)，'''，45分钟
*'''应用开发圆桌讨论: 1小时

*'''演讲：内核开发,Magnus Hagander，Involving in PostgreSQL Development'''，45分钟
*'''演讲: 内核开发,彭智勇，PostgreSQL 内核简介'''，45分钟
*'''演讲: 内核开发,张孝(中国人民大学)，《高校数据库教学中PostgreSQL的学习、使用与定制》简介'''，45分钟
:本报告主要报告在高校的数据库教学中如何利用PostgreSQL这样的开源数据库系统来了帮助学生切实从“白盒”角度感受一个大型数据库管理系统并深化有关数据库相关理论的学习与认知。报告将从入门级入手介绍如何由外及内地学习和了解PostgreSQL的基本特点并进行系统从无到有的建立。进一步来介绍如何使用PostgreSQL来满足教学(比如数据库概论)的一些课程要求以及对某些数据库应用的支持。此外，还会根据教学中一些高级内容(比如针对研究生的《数据库原理与实现》的要求)介绍如何对PostgreSQL进行内核级的改造以提供新的系统特性或功能增强。
*'''演讲: 内核开发,Cao Yu(EMC),Multi-Instance Aware Query Processing'''，45分钟
:It is not uncommon for analytical database queries to contain multiple instances of the same (base or derived) relation. Unfortunately, almost all of the conventional relational query processing techniques are oblivious to these instances and instead deal with them as independent relations. As a result, the query evaluation performance would be suboptimal. This talk will describe our research on the problem of optimizing complex queries with multiple relational instances, which surprisingly has never received systematic or specialized public studies in the past. We investigate three fundamental query execution operations, i.e. table scan, table sorting and table join, to exploit the corresponding optimization opportunities when these operations involve multiple instances.

:First, we present a light-weight multi-instance-aware plan evaluation engine that enables multiple instances of a relation to share one physical table scan. Second, we develop a sort-sharing-aware query processing framework to maximize the effects of sharing and collaboration during achieving different sorting requirements for multiple instances. Third, we propose an efficient algorithm for performing self-join operations between two instances and with join predicates involving two distinct instances. In all the above works, we validate our techniques by integrating them into PostgreSQL and testing their effectiveness using TPC benchmarks.
*'''演讲: 内核开发,孙鹏,'''，45分钟
*'''内核开发圆桌讨论: 1小时

*'''演讲: 李元佳,PostgreSQL用户会介绍'''，30分钟
*'''颁奖礼''' 30分钟

== 大会演讲嘉宾 SPEAKERS ==
* '''[http://www.hagander.net/ Magnus Hagander]'''
:Core Team Member and Major Developer of PostgreSQL Global Development Group
:Conference organizer at PostgreSQL Conference Europe
:Principal Database Consultant and Open Source Expert at Redpill Linpro
:President of the Board at PostgreSQL Europe

*'''[http://www.linkedin.com/profile/view?id=16308658&locale=en_US&trk=tyah Simon Riggs]'''

:Major Developer & Committer at PostgreSQL Global Development Group and CTO and Database Architect at 2ndQuadrant.
:Professional developer and consultant for PostgreSQL, following on from 20 years of experience with a variety of database technologies. Regular conference speaker.
:Enterprise-level experience working from within startup businesses product/service companies, including 2 successful IPOs.

*'''[http://www.intellilink.co.jp/plan/corporate/fellow_OSS-DB.html 铃木幸一Suzuki Koichi]'''

:Fellow at NTT DATA Intellilink Corporation

:After joining NTT Laboratory, Koichi Suzuki was involved in the following R&D activities:
::Extended Unix Code (EUC) development and Unicode standardization,
::Oracle port to NTT's proprietary Unix workstations,
::Object-Relation Databae Management System development (UniSQL), and
::PostgreSQL and Postgres-XC development.
::From 1991 to 1993, he was a guest researcher in MIT.

: 
:[http://sourceforge.jp/projects/nttdatagroup-oss-square/wiki/koichi_suzuki Official web page](in Japanese) 
:[http://postgres-xc.sourceforge.net/ Postgres-XC]

*'''彭智勇 Peng zhiyong'''

:日本京都大学工学博士，武汉大学计算机学院副院长、教授、博士生导师，中国计算机协会数据库专业委员会委员，国家信息产业部数据库标准工作组成员，武汉市电子政务宽带网络平台软件系统总体设计专家组成员，国内外许多学术会议程序委员会的委员。1985年毕业于武汉大学计算机科学系，获理学学士学位。1988年毕业于国防科技大学计算机系，获工学硕士学位。1995年毕业于日本京都大学信息科学系, 获工学博士学位。1995－1997年在日本京都高度技术研究所工作，研究员。1997－2000年在美国惠普公司的研究所工作，研究员。2001-2002年在武汉大学计算机科学与技术博士后流动站从事博士后研究工作。

*'''张孝 Zhang Xiao'''

:中国人民大学信息学院副教授，中科院计算所博士，中国人民大学硕士及学士，师从中国著名数据库专家王珊教授。

:1997年以访问学者的身份在香港中文大学系统工程与工程管理系从事合作研究与开发。2006年在印第安纳大学DSI&DDE实验室作为访问学者进行e-Science相关的元数据管理和数据出处领域访问研究。
:主要研究领域包括：并行数据库系统、分布式数据库系统、移动数据库等。尤其擅长大型数据库系统体系的原理分析、设计和实现技术，熟悉开源数据库系统PostgreSQL源代码。近期研究兴趣集中在：数据库体系结构、大规模非结构化与智能视频数据管理、数据库关键词检索等。
:从1996年以来作为主要技术骨干或核心骨干先后参与多项国家科技攻关项目、国家自然科学基金、北京市重大科技项目及国家863项目。先后获得多项省部级奖励，包括教育部科技进步二等奖1次，北京市科技进步一等奖1次、二等奖2次。独立主持有国家自然科学基金、核高基专项子课题以及国际企业的合作项目等。
:目前是中国计算机学会高级会员和中国计算机学会虚拟现实与可视化专委会委员、ACM协会会员。先后担任APWEB 2011本地主席、国际研讨会WAIM/USD'2012 和国际研讨会APWeb/WAIM DBIR09程序委员会联合主席以及NDBC 2010 Demo主席等学术兼职。先后在《软件学报》、《计算机学报》、《计算机研究与发展》等期刊杂志以及ICDE等国际会议上单独或联合发表论文20余篇，参与王珊教授主编的3本著作的编写工作。主要担任《数据结构》、《数据库原理与实现》、《PostgreSQL源代码阅读与分析》等课程的教学工作。

*何伟平

*唐诚(阿里巴巴)
:阿里巴巴公司数据库专家，精通greenplum和PostgreSQL数据库，为公司这一技术领域的带头人。也精通oracle数据库和AIX小型机，精通C/C++编程。
*德哥(斯凯网络)
:斯凯网络DBA主管，多年数据库平台工作经验,熟悉Oracle,PostgreSQL,EnterpriseDB,GreenPlum,mongoDB等多种数据库平台,熟悉OS,存储等.负责斯凯网络数据库架构设计,性能调优与维护,存储系统设计与维护,OS维护等工作.
:Digoal is the cheif DBA in Sky-mobi which runs the largest mobile app market in China, he manages a system consisting of over 300 PostgreSQL nodes, he will share us with his experience in managing PostgreSQL.
*Francs(斯凯网络)
*Gavin Yang(VMWARE)
*Cao Yu(EMC)
:Yu is currently working at EMC Labs China as a senior research scientist, after receiving his Ph.D. from National University of Singapore. His broad research interest lies in large-scale data management. More specifically, he does system-oriented research on database query processing and optimization, massive data storage and MapReduce-based big data analytics. He has published papers on top venues like SIGMOD, ICDE, EDBT, VLDB Journal, etc.
*萧少聪，
:曾任职于广东省Linux技术服务中心及红帽中国区唯一总代理，担任开源架构讲师及负责Red Hat系统开源产品华南地区技术顾问及架构设计工作。06年通过红帽RHCE认证，并获得红帽RHCI认证讲师资格，09年通过红帽全球最高认证 RHCA，成为国内前20名考取此认证的架构师。2012年成为EnterpriseDB公司在大中华区首位官方认证的 Postgres数据库讲师，同年协助李元佳等人筹建PostgresQL中国用户组。现任北京神州立诚科技有限公司技术总监，拥有多年开发、网络架构设计及项目管理经验，专注于开源Linux系统管理及Postgres数据库、优化、集群系统、云-虚拟架构设计领域。

*''孙鹏''
:中国科学院计算技术研究所工学博士，美国北德克萨斯大学访问学者，现任中国科学院软件研究所综合信息系统技术国家级重点实验室助理研究员，研究方向为空间数据库和空间数据库挖掘。
*李元佳,

== 大会预算 Budget==

我们在征集大会的赞助商，请赞助我们的大会，帮助我们大会顺利举行。
We are recruiting sponsors for the conference to help us hold this conference.

*预算约11万 Spending 110,000 RMB
**外宾旅费费用6万 Travel funding for foreign speakers 60,000 RMB （机票加酒店及车辆接送等每人约2万， 3 Guestes, each is about 20,000 ）
**大会场地 Conference Room 41,920 RMB（两天会议厅，加2天培训及3个分会场教室，另加投影仪等费用）
**用户礼品 Attendee Gift 6,000 RMB（T恤200件x30)
**购物袋胸卡 Bag 3,000 RMB (200本x15元)

*收入约11万 Income 110,000 RMB
**赞助 Sponsor 50,000RMB
**门票 Ticket 60,000RMB (300x200元=6万）

== 参与我们 Participate ==

''演讲者''

欢迎在PostgreSQL的企业应用、架构设计、运维管理、应用开发等方面有心得的朋友，发表演讲。如果你有需要发表的内容，请联系 galylee@gmail.com

''志愿者''

请帮助我们宣传大会，在你的网站，或者在论坛，或者在其他大会，告诉大家PG全国大会的举行信息。

''赞助''

我们是非盈利的组织，单单凭我们的力量无法承担大会的会场等相关的运营费用，只有相关企业的赞助和参与才有可能有必要的资源在国内培养PostgreSQL社区的形成。更多的赞助，可以让我们能邀请到更重量级的嘉宾为我们演讲，可以让我们有个交流和参与的平台。需要赞助的包括：场地费用及宣传品、邀请国外嘉宾的机票及食宿、嘉宾的演讲资料印刷、各种小礼物、大会首日晚上的酒会等等。。

''捐赠''

我们是旨在推广PG在中国发展的非营利的团体，欢迎企业为PG社区进行捐赠，捐赠的款项将完全用于PG社区的推广，包括官方文档的翻译、社区网站的托管、PG的技术交流会、PG大会的运营等。

[http://wiki.postgresql.org/wiki/Pgconfchina2012-admin 大会组织]

[[Category:PostgreSQL Events]]

Pgconfchina2012

2012-05-07T12:22:21Z

Dfetter: /* 大会预算 Buget */

== PostgreSQL Conference China 2012 ==

PostgreSQL中国用户会全国大会是由PostgreSQL中国用户会(CPUG)主办的旨在促进PostgreSQL在中国发展的非营利性的会议年度大会，大会是分享PostgreSQL的最佳使用实践、学习最新的功能特性、结交本领域的朋友的最佳场所。

2012年度大会将于2012年6月14日-17日在北京举行，中国人民大学信息学院承办。其中6月14日-15日是面向初级人员的入门培训，6月16(周六),17(周日)日是正式大会。本次大会将邀请到社区的核心组员Magnus Hagander,主要开发人员Simon Rigg、PG-XC的首席架构师铃木幸一(Suzuki Koichi)及其他海外专家为本次大会分享最前沿的PostgreSQL方面的信息，同时还有业界的资深人员作相关演讲。

PostgresQL User Group Conference China which organized by CPUG(China Postgres User Group) is an annual conference for PostgreSQL users in China, the conference is a hub for learning new features, sharing the know-how, and making friends about PostgreSQL.

PostgresQL User Group Conference China 2012 will be on 14-17 June 2012 at Renmin University of China in Beijing with two days of Tutorials on 14-15 June 2012. Magnus Hagander,Simon Rigg and Suzuki Koichi from community will also join this conference to give keynote speachs.

== 信息 Information ==

'''日期 DATE''': June 14-17, 2012

'''地点 LOCATION''': 中国人民大学 Remin University of China, Beijing，China

'''地址 ADDRESS''':

'''主办 Endorsed by''': CPUG(China PostgreSQL User Group) 中国PostgreSQL用户会

'''承办 Organizer''': 中国人民大学信息学院

'''协办''': IT168盛拓传媒

'''赞助支持伙伴 SPONSORS''':

'''内容 TOPIC''': PostgreSQL的企业应用、架构设计、运维管理、应用开发

'''费用 FEE''': 公司名义：300RMB(由于大会目前缺乏赞助商，所以需要门票收费，解决资金不足问题, 具体预算见下面),个人名义：200RMB(不提供发票), 学生100RMB(需提供学生证,不提供发票)。

'''缴费方法 ''':
银行
开户人
账号：

注1：如需开发票，请发邮件联系 galylee at gmail.com
注2：本次缴费由PG中国用户会负责，与IT168无任何关系，如产生任何纠纷由PG中国用户会负责，有问题请直接联系李元佳 Galylee at gmail.com 13710389225。

'''餐费 Lunch FEE''' 自助餐 120元/人(两天) 如需预定请注明

'''其他赞助商'''

'''参加方法 REGISTRATION''':
：本届大会将由IT168负责本次大会的报名活动，届时请参考相关主页。

'''联系方式 CONTACT''':

如有任何疑问欢迎联系。
Please contact if you have any questions.
大会会务负责人 Conference Orginizer：李元佳 Galy Lee
手机 Mobile：+86-13710389225
邮件 Email：galylee at gmail.com

'''重要日期 IMPORTANT DATES'''

4月月1日报名开始
6月1日报名截至

==大会主题Topics==

6月14日-15日将是面向DBA入门培训的课程。 6月16日-17日是大会的演讲，大会安排在三个分会场举行，来自国内外的专家将会就PostgreSQL的话题进行演讲，演讲的主要主题如下：
*系统使用PostgreSQL的架构(包括HA，集群，灾备等)
*PostgreSQL的监控、配置、各种辅助工具
*各种数据库向PostgreSQL的迁移
*使用PostgreSQL的数据分析、数据仓库仓库
*性能调优、性能基线测试
*PostgreSQL的分区
*集群，复制
*实际的应用案例
*使用PostgreSQL的地理信息系统
*利用SSD等新技术提高PostgreSQL的性能
*PostgreSQL 9.2的新功能
*PostgreSQL的新特性的开发、中文相关的全文检索等
*PostgreSQL的内核分析，研究，以及教学上的应用

A Two-day free Postgres DBA training will be given for people who want to learn PostgreSQL administration in the first two days. In 16-17 June, and the conference will be organized in three tracks, PostgreSQL experts from local and community will give talks about:
*System architecture for using PostgreSQL
*Migration of production systems from another database
*Data warehousing
*Tuning PostgreSQL for different work loads
*Replication and clustering
*Benchmarking and performance engineering
*Case studies
*Location-aware and mapping software with PostGIS
*PostgreSQL 9.2 features
*Research and teaching with PostgreSQL
Community major developers: Simmon Rigg, Suzuki Koichi will give talks about 9.2 features, PG-XC and clustering solutions.

==Postgres集群研讨会 Postgres Clustering Summit ==

*PG-XC专题会议 6.14日下午(仅限于相关公司或者个人)，讨论如何参与到PG-XC的开发等议题。

== 大会议程 Schedule (subject to change) ==
===基础培训专场 Basic Tranning===

*6月14日(周四) 9:00-17:00
**PostgresQL 核心架构基础(Process/Storage/Momery等)
**PostgresQL 安装及文件结构
**PostgresQL 配置基础
**PostgresQL 数据库逻辑结构(Database/Schema/Tablespace等)
**PostgresQL 数据备份及恢复
**PostgresQL 数据库权限及安全管理
*6月15日(周五) 9:00 – 17:00
**PostgresQL 基于时间点的数据恢复(Point-in Time Recovery)
**PostgresQL 运行时维护管理(MVCC/Vacuum/Reindex等)
**PostgresQL 存储过程及调试(pg/plsql，pgAdminIII Debuger)
**PostgresQL 监控排错基础
**PostgreSQL优化培训

*以下内容只进行简要概念介绍(Day2)：
**数据库集群概论
**PostgresQL Hot-Standby and Stream Replication简介
**PostgresQL 高可用性集群架构简介
**PostgresQL PGPool 读写分离架构简介
**PostgresQL 集中管理及性能优化基础

===大会 Conference===

*第一天： 6月16日(周六)

====主场1 ====
**会场主持:李元佳
**9:00-9：05大会介绍
**9:05-9:15大会致辞
**9:15-10:00 主题演讲1 Magnus Hagander，PostgreSQL 9.2 features and Roadmap
**10:00-10:45 主题演讲1-1 Suzuki Koichi, Postgres-XC, Read/Write scalable PostgreSQL cluster
**10:45-11:00 主题演讲1-2 Suzuki Koichi, PostgreSQL usage in NTT
**11:00-11:45 主题演讲2 Simon Rigg,
**12:00-12:15 集体照相

==== 分场1 DBA专场 ====
==== 分场2 PG内核开发专场 ====
==== 分场3 应用开发专场 ====

晚餐：18：00

*第二天6月17日(周日)
上午
会场1：
会场2：
会场3：
下午：
讨论、提问

===PG-XC专场 PG XC Summit ===
*时间：6.14日 14:00 - 17:00
*地点：人民大学
*议题：
**PG-XC培训 14:00 - 16:00
**PG-XC讨论 16:00 - 17:00
*参与嘉宾：PG-XC首席架构师铃木幸一 Suzuki Koichi

== 大会演讲 TOPICS ==
*'''主题演讲Keynote: Magnus Hagander，PostgreSQL 9.2的新功能及路线图，PostgreSQL 9.2 features and Roadmap''', 45分钟
*'''主题演讲Keynote: Koichi Suzuki，Postgres-XC读写可扩展的PostgreSQL集群,Postgres-XC, Read/Write scalable PostgreSQL cluster''', 45分钟
:Postgres-XC is PostgreSQL-based database cluster based upon shared-nothing configuration. Postgres-XC (simply XC) provides both read and write scalability. XC's servers are symmetric so that applications can connect any of the servers. With more servers, you can get more performance. No dedicated hardware is required. You need only a commodity hardware. Each server provides single global database view. Complete transaction management features are provided just as single PostgreSQL.

:The talk will cover the motivation, architecture, performance of XC, as well as high-availability features, milestone and how to be a part of XC community. Architecture will be covered how how to provide full-fledged transaction property and both read/write scalability, as well as distributed query processing. High-availability feature will cover how to backup each server and components for integration.
*'''主题演讲Keynote: Simon Rigg，企业级的PostgreSQL及未来的发展方向 Enterprise PostgreSQL & Futures''', 45分钟
*'''主题演讲Talks: Simon Rigg，PostgreSQL流复制及未来的发展方向 PostgreSQL Replication & Futures''', 45分钟

*'''专家圆桌讨论Panel Discussion:Magnus, Simon, 彭智勇， 1小时

*'''演讲Talks:何伟平 He Weiping(Laser)， 45小时
*'''演讲Talks: DBA管理,Koichi Suzuki，PostgreSQL在电信市场的应用, PostgreSQL use in telecommunication market (NTT group)'''，15分钟
*'''演讲Talks: DBA管理,萧少聪 Scott xiu，PostgreSQL的流复制'''，45分钟
*'''演讲Talks: DBA管理,唐诚(阿里巴巴) Tang Cheng(Alibaba),greenplum数据库经验谈'''，45分钟
:1. greenplum的架构简介 2. greenplum 与　hadoop的对比 3. greenplum 的执行计划 4. 日常维护经验谈

*'''演讲: DBA管理,德哥(斯凯网络) Digoal(Skymobi)，PostgreSQL 杂谈'''，45分钟
*'''演讲: DBA管理,Francs(斯凯网络),Francs(Skymobi)，PostgreSQL vs Oracle'''，45分钟
*'''DBA 圆桌讨论 Panel Discussion:

*'''演讲: 应用开发,(去哪儿)， '''，45分钟
*'''演讲: 应用开发,， PostGIS 应用'''，45分钟
*'''演讲: 应用开发,Gavin Yang(VMWARE)， PostgreSQL的数据分析工具MADlib, In-Database Analytics with MADlib'''，45分钟
:MADlib is an open-source library on RDBMS for scalable in-database big data analytics. It provides data-parallel implementations of mathematical, statistical and machine learning methods for structured and unstructured data. This talk introduces some of the problems we are tackling in the MADlib initiative and the solutions for them. We will also talk about our recent work in building decision trees and random forests within databases.
*'''演讲: 应用开发,蔡红雨(高鹏)，'''，45分钟
*'''应用开发圆桌讨论: 1小时

*'''演讲：内核开发,Magnus Hagander，Involving in PostgreSQL Development'''，45分钟
*'''演讲: 内核开发,彭智勇，PostgreSQL 内核简介'''，45分钟
*'''演讲: 内核开发,张孝(中国人民大学)，《高校数据库教学中PostgreSQL的学习、使用与定制》简介'''，45分钟
:本报告主要报告在高校的数据库教学中如何利用PostgreSQL这样的开源数据库系统来了帮助学生切实从“白盒”角度感受一个大型数据库管理系统并深化有关数据库相关理论的学习与认知。报告将从入门级入手介绍如何由外及内地学习和了解PostgreSQL的基本特点并进行系统从无到有的建立。进一步来介绍如何使用PostgreSQL来满足教学(比如数据库概论)的一些课程要求以及对某些数据库应用的支持。此外，还会根据教学中一些高级内容(比如针对研究生的《数据库原理与实现》的要求)介绍如何对PostgreSQL进行内核级的改造以提供新的系统特性或功能增强。
*'''演讲: 内核开发,Cao Yu(EMC),Multi-Instance Aware Query Processing'''，45分钟
:It is not uncommon for analytical database queries to contain multiple instances of the same (base or derived) relation. Unfortunately, almost all of the conventional relational query processing techniques are oblivious to these instances and instead deal with them as independent relations. As a result, the query evaluation performance would be suboptimal. This talk will describe our research on the problem of optimizing complex queries with multiple relational instances, which surprisingly has never received systematic or specialized public studies in the past. We investigate three fundamental query execution operations, i.e. table scan, table sorting and table join, to exploit the corresponding optimization opportunities when these operations involve multiple instances.

:First, we present a light-weight multi-instance-aware plan evaluation engine that enables multiple instances of a relation to share one physical table scan. Second, we develop a sort-sharing-aware query processing framework to maximize the effects of sharing and collaboration during achieving different sorting requirements for multiple instances. Third, we propose an efficient algorithm for performing self-join operations between two instances and with join predicates involving two distinct instances. In all the above works, we validate our techniques by integrating them into PostgreSQL and testing their effectiveness using TPC benchmarks.
*'''演讲: 内核开发,孙鹏,'''，45分钟
*'''内核开发圆桌讨论: 1小时

*'''演讲: 李元佳,PostgreSQL用户会介绍'''，30分钟
*'''颁奖礼''' 30分钟

== 大会演讲嘉宾 SPEAKERS ==
* '''[http://www.hagander.net/ Magnus Hagander]'''
:Core Team Member and Major Developer of PostgreSQL Global Development Group
:Conference organizer at PostgreSQL Conference Europe
:Principal Database Consultant and Open Source Expert at Redpill Linpro
:President of the Board at PostgreSQL Europe

*'''[http://www.linkedin.com/profile/view?id=16308658&locale=en_US&trk=tyah Simon Riggs]'''

:Major Developer & Committer at PostgreSQL Global Development Group and CTO and Database Architect at 2ndQuadrant.
:Professional developer and consultant for PostgreSQL, following on from 20 years of experience with a variety of database technologies. Regular conference speaker.
:Enterprise-level experience working from within startup businesses product/service companies, including 2 successful IPOs.

*'''[http://www.intellilink.co.jp/plan/corporate/fellow_OSS-DB.html 铃木幸一Suzuki Koichi]'''

:Fellow at NTT DATA Intellilink Corporation

:After joining NTT Laboratory, Koichi Suzuki was involved in the following R&D activities:
::Extended Unix Code (EUC) development and Unicode standardization,
::Oracle port to NTT's proprietary Unix workstations,
::Object-Relation Databae Management System development (UniSQL), and
::PostgreSQL and Postgres-XC development.
::From 1991 to 1993, he was a guest researcher in MIT.

: 
:[http://sourceforge.jp/projects/nttdatagroup-oss-square/wiki/koichi_suzuki Official web page](in Japanese) 
:[http://postgres-xc.sourceforge.net/ Postgres-XC]

*'''彭智勇 Peng zhiyong'''

:日本京都大学工学博士，武汉大学计算机学院副院长、教授、博士生导师，中国计算机协会数据库专业委员会委员，国家信息产业部数据库标准工作组成员，武汉市电子政务宽带网络平台软件系统总体设计专家组成员，国内外许多学术会议程序委员会的委员。1985年毕业于武汉大学计算机科学系，获理学学士学位。1988年毕业于国防科技大学计算机系，获工学硕士学位。1995年毕业于日本京都大学信息科学系, 获工学博士学位。1995－1997年在日本京都高度技术研究所工作，研究员。1997－2000年在美国惠普公司的研究所工作，研究员。2001-2002年在武汉大学计算机科学与技术博士后流动站从事博士后研究工作。

*'''张孝 Zhang Xiao'''

:中国人民大学信息学院副教授，中科院计算所博士，中国人民大学硕士及学士，师从中国著名数据库专家王珊教授。

:1997年以访问学者的身份在香港中文大学系统工程与工程管理系从事合作研究与开发。2006年在印第安纳大学DSI&DDE实验室作为访问学者进行e-Science相关的元数据管理和数据出处领域访问研究。
:主要研究领域包括：并行数据库系统、分布式数据库系统、移动数据库等。尤其擅长大型数据库系统体系的原理分析、设计和实现技术，熟悉开源数据库系统PostgreSQL源代码。近期研究兴趣集中在：数据库体系结构、大规模非结构化与智能视频数据管理、数据库关键词检索等。
:从1996年以来作为主要技术骨干或核心骨干先后参与多项国家科技攻关项目、国家自然科学基金、北京市重大科技项目及国家863项目。先后获得多项省部级奖励，包括教育部科技进步二等奖1次，北京市科技进步一等奖1次、二等奖2次。独立主持有国家自然科学基金、核高基专项子课题以及国际企业的合作项目等。
:目前是中国计算机学会高级会员和中国计算机学会虚拟现实与可视化专委会委员、ACM协会会员。先后担任APWEB 2011本地主席、国际研讨会WAIM/USD'2012 和国际研讨会APWeb/WAIM DBIR09程序委员会联合主席以及NDBC 2010 Demo主席等学术兼职。先后在《软件学报》、《计算机学报》、《计算机研究与发展》等期刊杂志以及ICDE等国际会议上单独或联合发表论文20余篇，参与王珊教授主编的3本著作的编写工作。主要担任《数据结构》、《数据库原理与实现》、《PostgreSQL源代码阅读与分析》等课程的教学工作。

*何伟平

*唐诚(阿里巴巴)
:阿里巴巴公司数据库专家，精通greenplum和PostgreSQL数据库，为公司这一技术领域的带头人。也精通oracle数据库和AIX小型机，精通C/C++编程。
*德哥(斯凯网络)
:斯凯网络DBA主管，多年数据库平台工作经验,熟悉Oracle,PostgreSQL,EnterpriseDB,GreenPlum,mongoDB等多种数据库平台,熟悉OS,存储等.负责斯凯网络数据库架构设计,性能调优与维护,存储系统设计与维护,OS维护等工作.
:Digoal is the cheif DBA in Sky-mobi which runs the largest mobile app market in China, he manages a system consisting of over 300 PostgreSQL nodes, he will share us with his experience in managing PostgreSQL.
*Francs(斯凯网络)
*Gavin Yang(VMWARE)
*Cao Yu(EMC)
:Yu is currently working at EMC Labs China as a senior research scientist, after receiving his Ph.D. from National University of Singapore. His broad research interest lies in large-scale data management. More specifically, he does system-oriented research on database query processing and optimization, massive data storage and MapReduce-based big data analytics. He has published papers on top venues like SIGMOD, ICDE, EDBT, VLDB Journal, etc.
*萧少聪，
:曾任职于广东省Linux技术服务中心及红帽中国区唯一总代理，担任开源架构讲师及负责Red Hat系统开源产品华南地区技术顾问及架构设计工作。06年通过红帽RHCE认证，并获得红帽RHCI认证讲师资格，09年通过红帽全球最高认证 RHCA，成为国内前20名考取此认证的架构师。2012年成为EnterpriseDB公司在大中华区首位官方认证的 Postgres数据库讲师，同年协助李元佳等人筹建PostgresQL中国用户组。现任北京神州立诚科技有限公司技术总监，拥有多年开发、网络架构设计及项目管理经验，专注于开源Linux系统管理及Postgres数据库、优化、集群系统、云-虚拟架构设计领域。

*''孙鹏''
:中国科学院计算技术研究所工学博士，美国北德克萨斯大学访问学者，现任中国科学院软件研究所综合信息系统技术国家级重点实验室助理研究员，研究方向为空间数据库和空间数据库挖掘。
*李元佳,

== 大会预算 Budget==

我们在征集大会的赞助商，请赞助我们的大会，帮助我们大会顺利举行。
We are recruiting sponsors for the conference to help us hold this conference.

*预算约11万 Spending 110,000 RMB
**外宾旅费费用6万 Travel funding for foreign speakers 60,000 RMB （机票加酒店及车辆接送等每人约2万， 3 Guestes, each is about 20,000 ）
**大会场地 Conference Room 41,920 RMB（两天会议厅，加2天培训及3个分会场教室，另加投影仪等费用）
**用户礼品 Attendee Gift 6,000 RMB（T恤200件x30)
**购物袋胸卡 Bag 3,000 RMB (200本x15元)

*收入约11万 Income 110,000 RMB
**赞助 Sponsor 50,000RMB
**门票 Ticket 60,000RMB (300x200元=6万）

== 参与我们 Participate ==

''演讲者''

欢迎在PostgreSQL的企业应用、架构设计、运维管理、应用开发等方面有心得的朋友，发表演讲。如果你有需要发表的内容，请联系 galylee@gmail.com

''志愿者''

请帮助我们宣传大会，在你的网站，或者在论坛，或者在其他大会，告诉大家PG全国大会的举行信息。

''赞助''

我们是非盈利的组织，单单凭我们的力量无法承担大会的会场等相关的运营费用，只有相关企业的赞助和参与才有可能有必要的资源在国内培养PostgreSQL社区的形成。更多的赞助，可以让我们能邀请到更重量级的嘉宾为我们演讲，可以让我们有个交流和参与的平台。需要赞助的包括：场地费用及宣传品、邀请国外嘉宾的机票及食宿、嘉宾的演讲资料印刷、各种小礼物、大会首日晚上的酒会等等。。

''捐赠''

我们是旨在推广PG在中国发展的非营利的团体，欢迎企业为PG社区进行捐赠，捐赠的款项将完全用于PG社区的推广，包括官方文档的翻译、社区网站的托管、PG的技术交流会、PG大会的运营等。

[http://wiki.postgresql.org/wiki/Pgconfchina2012-admin 大会组织]

[[Category:PostgreSQL Events]]

Pgconfchina2012

2012-05-07T12:17:08Z

Dfetter: /* 大会演讲嘉宾 SPEAKERS */

== PostgreSQL Conference China 2012 ==

PostgreSQL中国用户会全国大会是由PostgreSQL中国用户会(CPUG)主办的旨在促进PostgreSQL在中国发展的非营利性的会议年度大会，大会是分享PostgreSQL的最佳使用实践、学习最新的功能特性、结交本领域的朋友的最佳场所。

2012年度大会将于2012年6月14日-17日在北京举行，中国人民大学信息学院承办。其中6月14日-15日是面向初级人员的入门培训，6月16(周六),17(周日)日是正式大会。本次大会将邀请到社区的核心组员Magnus Hagander,主要开发人员Simon Rigg、PG-XC的首席架构师铃木幸一(Suzuki Koichi)及其他海外专家为本次大会分享最前沿的PostgreSQL方面的信息，同时还有业界的资深人员作相关演讲。

PostgresQL User Group Conference China which organized by CPUG(China Postgres User Group) is an annual conference for PostgreSQL users in China, the conference is a hub for learning new features, sharing the know-how, and making friends about PostgreSQL.

PostgresQL User Group Conference China 2012 will be on 14-17 June 2012 at Renmin University of China in Beijing with two days of Tutorials on 14-15 June 2012. Magnus Hagander,Simon Rigg and Suzuki Koichi from community will also join this conference to give keynote speachs.

== 信息 Information ==

'''日期 DATE''': June 14-17, 2012

'''地点 LOCATION''': 中国人民大学 Remin University of China, Beijing，China

'''地址 ADDRESS''':

'''主办 Endorsed by''': CPUG(China PostgreSQL User Group) 中国PostgreSQL用户会

'''承办 Organizer''': 中国人民大学信息学院

'''协办''': IT168盛拓传媒

'''赞助支持伙伴 SPONSORS''':

'''内容 TOPIC''': PostgreSQL的企业应用、架构设计、运维管理、应用开发

'''费用 FEE''': 公司名义：300RMB(由于大会目前缺乏赞助商，所以需要门票收费，解决资金不足问题, 具体预算见下面),个人名义：200RMB(不提供发票), 学生100RMB(需提供学生证,不提供发票)。

'''缴费方法 ''':
银行
开户人
账号：

注1：如需开发票，请发邮件联系 galylee at gmail.com
注2：本次缴费由PG中国用户会负责，与IT168无任何关系，如产生任何纠纷由PG中国用户会负责，有问题请直接联系李元佳 Galylee at gmail.com 13710389225。

'''餐费 Lunch FEE''' 自助餐 120元/人(两天) 如需预定请注明

'''其他赞助商'''

'''参加方法 REGISTRATION''':
：本届大会将由IT168负责本次大会的报名活动，届时请参考相关主页。

'''联系方式 CONTACT''':

如有任何疑问欢迎联系。
Please contact if you have any questions.
大会会务负责人 Conference Orginizer：李元佳 Galy Lee
手机 Mobile：+86-13710389225
邮件 Email：galylee at gmail.com

'''重要日期 IMPORTANT DATES'''

4月月1日报名开始
6月1日报名截至

==大会主题Topics==

6月14日-15日将是面向DBA入门培训的课程。 6月16日-17日是大会的演讲，大会安排在三个分会场举行，来自国内外的专家将会就PostgreSQL的话题进行演讲，演讲的主要主题如下：
*系统使用PostgreSQL的架构(包括HA，集群，灾备等)
*PostgreSQL的监控、配置、各种辅助工具
*各种数据库向PostgreSQL的迁移
*使用PostgreSQL的数据分析、数据仓库仓库
*性能调优、性能基线测试
*PostgreSQL的分区
*集群，复制
*实际的应用案例
*使用PostgreSQL的地理信息系统
*利用SSD等新技术提高PostgreSQL的性能
*PostgreSQL 9.2的新功能
*PostgreSQL的新特性的开发、中文相关的全文检索等
*PostgreSQL的内核分析，研究，以及教学上的应用

A Two-day free Postgres DBA training will be given for people who want to learn PostgreSQL administration in the first two days. In 16-17 June, and the conference will be organized in three tracks, PostgreSQL experts from local and community will give talks about:
*System architecture for using PostgreSQL
*Migration of production systems from another database
*Data warehousing
*Tuning PostgreSQL for different work loads
*Replication and clustering
*Benchmarking and performance engineering
*Case studies
*Location-aware and mapping software with PostGIS
*PostgreSQL 9.2 features
*Research and teaching with PostgreSQL
Community major developers: Simmon Rigg, Suzuki Koichi will give talks about 9.2 features, PG-XC and clustering solutions.

==Postgres集群研讨会 Postgres Clustering Summit ==

*PG-XC专题会议 6.14日下午(仅限于相关公司或者个人)，讨论如何参与到PG-XC的开发等议题。

== 大会议程 Schedule (subject to change) ==
===基础培训专场 Basic Tranning===

*6月14日(周四) 9:00-17:00
**PostgresQL 核心架构基础(Process/Storage/Momery等)
**PostgresQL 安装及文件结构
**PostgresQL 配置基础
**PostgresQL 数据库逻辑结构(Database/Schema/Tablespace等)
**PostgresQL 数据备份及恢复
**PostgresQL 数据库权限及安全管理
*6月15日(周五) 9:00 – 17:00
**PostgresQL 基于时间点的数据恢复(Point-in Time Recovery)
**PostgresQL 运行时维护管理(MVCC/Vacuum/Reindex等)
**PostgresQL 存储过程及调试(pg/plsql，pgAdminIII Debuger)
**PostgresQL 监控排错基础
**PostgreSQL优化培训

*以下内容只进行简要概念介绍(Day2)：
**数据库集群概论
**PostgresQL Hot-Standby and Stream Replication简介
**PostgresQL 高可用性集群架构简介
**PostgresQL PGPool 读写分离架构简介
**PostgresQL 集中管理及性能优化基础

===大会 Conference===

*第一天： 6月16日(周六)

====主场1 ====
**会场主持:李元佳
**9:00-9：05大会介绍
**9:05-9:15大会致辞
**9:15-10:00 主题演讲1 Magnus Hagander，PostgreSQL 9.2 features and Roadmap
**10:00-10:45 主题演讲1-1 Suzuki Koichi, Postgres-XC, Read/Write scalable PostgreSQL cluster
**10:45-11:00 主题演讲1-2 Suzuki Koichi, PostgreSQL usage in NTT
**11:00-11:45 主题演讲2 Simon Rigg,
**12:00-12:15 集体照相

==== 分场1 DBA专场 ====
==== 分场2 PG内核开发专场 ====
==== 分场3 应用开发专场 ====

晚餐：18：00

*第二天6月17日(周日)
上午
会场1：
会场2：
会场3：
下午：
讨论、提问

===PG-XC专场 PG XC Summit ===
*时间：6.14日 14:00 - 17:00
*地点：人民大学
*议题：
**PG-XC培训 14:00 - 16:00
**PG-XC讨论 16:00 - 17:00
*参与嘉宾：PG-XC首席架构师铃木幸一 Suzuki Koichi

== 大会演讲 TOPICS ==
*'''主题演讲Keynote: Magnus Hagander，PostgreSQL 9.2的新功能及路线图，PostgreSQL 9.2 features and Roadmap''', 45分钟
*'''主题演讲Keynote: Koichi Suzuki，Postgres-XC读写可扩展的PostgreSQL集群,Postgres-XC, Read/Write scalable PostgreSQL cluster''', 45分钟
:Postgres-XC is PostgreSQL-based database cluster based upon shared-nothing configuration. Postgres-XC (simply XC) provides both read and write scalability. XC's servers are symmetric so that applications can connect any of the servers. With more servers, you can get more performance. No dedicated hardware is required. You need only a commodity hardware. Each server provides single global database view. Complete transaction management features are provided just as single PostgreSQL.

:The talk will cover the motivation, architecture, performance of XC, as well as high-availability features, milestone and how to be a part of XC community. Architecture will be covered how how to provide full-fledged transaction property and both read/write scalability, as well as distributed query processing. High-availability feature will cover how to backup each server and components for integration.
*'''主题演讲Keynote: Simon Rigg，企业级的PostgreSQL及未来的发展方向 Enterprise PostgreSQL & Futures''', 45分钟
*'''主题演讲Talks: Simon Rigg，PostgreSQL流复制及未来的发展方向 PostgreSQL Replication & Futures''', 45分钟

*'''专家圆桌讨论Panel Discussion:Magnus, Simon, 彭智勇， 1小时

*'''演讲Talks:何伟平 He Weiping(Laser)， 45小时
*'''演讲Talks: DBA管理,Koichi Suzuki，PostgreSQL在电信市场的应用, PostgreSQL use in telecommunication market (NTT group)'''，15分钟
*'''演讲Talks: DBA管理,萧少聪 Scott xiu，PostgreSQL的流复制'''，45分钟
*'''演讲Talks: DBA管理,唐诚(阿里巴巴) Tang Cheng(Alibaba),greenplum数据库经验谈'''，45分钟
:1. greenplum的架构简介 2. greenplum 与　hadoop的对比 3. greenplum 的执行计划 4. 日常维护经验谈

*'''演讲: DBA管理,德哥(斯凯网络) Digoal(Skymobi)，PostgreSQL 杂谈'''，45分钟
*'''演讲: DBA管理,Francs(斯凯网络),Francs(Skymobi)，PostgreSQL vs Oracle'''，45分钟
*'''DBA 圆桌讨论 Panel Discussion:

*'''演讲: 应用开发,(去哪儿)， '''，45分钟
*'''演讲: 应用开发,， PostGIS 应用'''，45分钟
*'''演讲: 应用开发,Gavin Yang(VMWARE)， PostgreSQL的数据分析工具MADlib, In-Database Analytics with MADlib'''，45分钟
:MADlib is an open-source library on RDBMS for scalable in-database big data analytics. It provides data-parallel implementations of mathematical, statistical and machine learning methods for structured and unstructured data. This talk introduces some of the problems we are tackling in the MADlib initiative and the solutions for them. We will also talk about our recent work in building decision trees and random forests within databases.
*'''演讲: 应用开发,蔡红雨(高鹏)，'''，45分钟
*'''应用开发圆桌讨论: 1小时

*'''演讲：内核开发,Magnus Hagander，Involving in PostgreSQL Development'''，45分钟
*'''演讲: 内核开发,彭智勇，PostgreSQL 内核简介'''，45分钟
*'''演讲: 内核开发,张孝(中国人民大学)，《高校数据库教学中PostgreSQL的学习、使用与定制》简介'''，45分钟
:本报告主要报告在高校的数据库教学中如何利用PostgreSQL这样的开源数据库系统来了帮助学生切实从“白盒”角度感受一个大型数据库管理系统并深化有关数据库相关理论的学习与认知。报告将从入门级入手介绍如何由外及内地学习和了解PostgreSQL的基本特点并进行系统从无到有的建立。进一步来介绍如何使用PostgreSQL来满足教学(比如数据库概论)的一些课程要求以及对某些数据库应用的支持。此外，还会根据教学中一些高级内容(比如针对研究生的《数据库原理与实现》的要求)介绍如何对PostgreSQL进行内核级的改造以提供新的系统特性或功能增强。
*'''演讲: 内核开发,Cao Yu(EMC),Multi-Instance Aware Query Processing'''，45分钟
:It is not uncommon for analytical database queries to contain multiple instances of the same (base or derived) relation. Unfortunately, almost all of the conventional relational query processing techniques are oblivious to these instances and instead deal with them as independent relations. As a result, the query evaluation performance would be suboptimal. This talk will describe our research on the problem of optimizing complex queries with multiple relational instances, which surprisingly has never received systematic or specialized public studies in the past. We investigate three fundamental query execution operations, i.e. table scan, table sorting and table join, to exploit the corresponding optimization opportunities when these operations involve multiple instances.

:First, we present a light-weight multi-instance-aware plan evaluation engine that enables multiple instances of a relation to share one physical table scan. Second, we develop a sort-sharing-aware query processing framework to maximize the effects of sharing and collaboration during achieving different sorting requirements for multiple instances. Third, we propose an efficient algorithm for performing self-join operations between two instances and with join predicates involving two distinct instances. In all the above works, we validate our techniques by integrating them into PostgreSQL and testing their effectiveness using TPC benchmarks.
*'''演讲: 内核开发,孙鹏,'''，45分钟
*'''内核开发圆桌讨论: 1小时

*'''演讲: 李元佳,PostgreSQL用户会介绍'''，30分钟
*'''颁奖礼''' 30分钟

== 大会演讲嘉宾 SPEAKERS ==
* '''[http://www.hagander.net/ Magnus Hagander]'''
:Core Team Member and Major Developer of PostgreSQL Global Development Group
:Conference organizer at PostgreSQL Conference Europe
:Principal Database Consultant and Open Source Expert at Redpill Linpro
:President of the Board at PostgreSQL Europe

*'''[http://www.linkedin.com/profile/view?id=16308658&locale=en_US&trk=tyah Simon Riggs]'''

:Major Developer & Committer at PostgreSQL Global Development Group and CTO and Database Architect at 2ndQuadrant.
:Professional developer and consultant for PostgreSQL, following on from 20 years of experience with a variety of database technologies. Regular conference speaker.
:Enterprise-level experience working from within startup businesses product/service companies, including 2 successful IPOs.

*'''[http://www.intellilink.co.jp/plan/corporate/fellow_OSS-DB.html 铃木幸一Suzuki Koichi]'''

:Fellow at NTT DATA Intellilink Corporation

:After joining NTT Laboratory, Koichi Suzuki was involved in the following R&D activities:
::Extended Unix Code (EUC) development and Unicode standardization,
::Oracle port to NTT's proprietary Unix workstations,
::Object-Relation Databae Management System development (UniSQL), and
::PostgreSQL and Postgres-XC development.
::From 1991 to 1993, he was a guest researcher in MIT.

: 
:[http://sourceforge.jp/projects/nttdatagroup-oss-square/wiki/koichi_suzuki Official web page](in Japanese) 
:[http://postgres-xc.sourceforge.net/ Postgres-XC]

*'''彭智勇 Peng zhiyong'''

:日本京都大学工学博士，武汉大学计算机学院副院长、教授、博士生导师，中国计算机协会数据库专业委员会委员，国家信息产业部数据库标准工作组成员，武汉市电子政务宽带网络平台软件系统总体设计专家组成员，国内外许多学术会议程序委员会的委员。1985年毕业于武汉大学计算机科学系，获理学学士学位。1988年毕业于国防科技大学计算机系，获工学硕士学位。1995年毕业于日本京都大学信息科学系, 获工学博士学位。1995－1997年在日本京都高度技术研究所工作，研究员。1997－2000年在美国惠普公司的研究所工作，研究员。2001-2002年在武汉大学计算机科学与技术博士后流动站从事博士后研究工作。

*'''张孝 Zhang Xiao'''

:中国人民大学信息学院副教授，中科院计算所博士，中国人民大学硕士及学士，师从中国著名数据库专家王珊教授。

:1997年以访问学者的身份在香港中文大学系统工程与工程管理系从事合作研究与开发。2006年在印第安纳大学DSI&DDE实验室作为访问学者进行e-Science相关的元数据管理和数据出处领域访问研究。
:主要研究领域包括：并行数据库系统、分布式数据库系统、移动数据库等。尤其擅长大型数据库系统体系的原理分析、设计和实现技术，熟悉开源数据库系统PostgreSQL源代码。近期研究兴趣集中在：数据库体系结构、大规模非结构化与智能视频数据管理、数据库关键词检索等。
:从1996年以来作为主要技术骨干或核心骨干先后参与多项国家科技攻关项目、国家自然科学基金、北京市重大科技项目及国家863项目。先后获得多项省部级奖励，包括教育部科技进步二等奖1次，北京市科技进步一等奖1次、二等奖2次。独立主持有国家自然科学基金、核高基专项子课题以及国际企业的合作项目等。
:目前是中国计算机学会高级会员和中国计算机学会虚拟现实与可视化专委会委员、ACM协会会员。先后担任APWEB 2011本地主席、国际研讨会WAIM/USD'2012 和国际研讨会APWeb/WAIM DBIR09程序委员会联合主席以及NDBC 2010 Demo主席等学术兼职。先后在《软件学报》、《计算机学报》、《计算机研究与发展》等期刊杂志以及ICDE等国际会议上单独或联合发表论文20余篇，参与王珊教授主编的3本著作的编写工作。主要担任《数据结构》、《数据库原理与实现》、《PostgreSQL源代码阅读与分析》等课程的教学工作。

*何伟平

*唐诚(阿里巴巴)
:阿里巴巴公司数据库专家，精通greenplum和PostgreSQL数据库，为公司这一技术领域的带头人。也精通oracle数据库和AIX小型机，精通C/C++编程。
*德哥(斯凯网络)
:斯凯网络DBA主管，多年数据库平台工作经验,熟悉Oracle,PostgreSQL,EnterpriseDB,GreenPlum,mongoDB等多种数据库平台,熟悉OS,存储等.负责斯凯网络数据库架构设计,性能调优与维护,存储系统设计与维护,OS维护等工作.
:Digoal is the cheif DBA in Sky-mobi which runs the largest mobile app market in China, he manages a system consisting of over 300 PostgreSQL nodes, he will share us with his experience in managing PostgreSQL.
*Francs(斯凯网络)
*Gavin Yang(VMWARE)
*Cao Yu(EMC)
:Yu is currently working at EMC Labs China as a senior research scientist, after receiving his Ph.D. from National University of Singapore. His broad research interest lies in large-scale data management. More specifically, he does system-oriented research on database query processing and optimization, massive data storage and MapReduce-based big data analytics. He has published papers on top venues like SIGMOD, ICDE, EDBT, VLDB Journal, etc.
*萧少聪，
:曾任职于广东省Linux技术服务中心及红帽中国区唯一总代理，担任开源架构讲师及负责Red Hat系统开源产品华南地区技术顾问及架构设计工作。06年通过红帽RHCE认证，并获得红帽RHCI认证讲师资格，09年通过红帽全球最高认证 RHCA，成为国内前20名考取此认证的架构师。2012年成为EnterpriseDB公司在大中华区首位官方认证的 Postgres数据库讲师，同年协助李元佳等人筹建PostgresQL中国用户组。现任北京神州立诚科技有限公司技术总监，拥有多年开发、网络架构设计及项目管理经验，专注于开源Linux系统管理及Postgres数据库、优化、集群系统、云-虚拟架构设计领域。

*''孙鹏''
:中国科学院计算技术研究所工学博士，美国北德克萨斯大学访问学者，现任中国科学院软件研究所综合信息系统技术国家级重点实验室助理研究员，研究方向为空间数据库和空间数据库挖掘。
*李元佳,

== 大会预算 Buget==

我们在征集大会的赞助商，请赞助我们的大会，帮助我们大会顺利举行。
We are recruiting sponsors for the conference to help us hold this conference.

*预算约11万 Spending 110,000 RMB
**外宾旅费费用6万 Travel funding for foreign speakers 60,000 RMB （机票加酒店及车辆接送等每人约2万， 3 Guestes, each is about 20,000 ）
**大会场地 Conference Room 41,920 RMB（两天会议厅，加2天培训及3个分会场教室，另加投影仪等费用）
**用户礼品 Attendee Gift 6,000 RMB（T恤200件x30)
**购物袋胸卡 Bag 3,000 RMB (200本x15元)

*收入约11万 Income 110,000 RMB
**赞助 Sponsor 50,000RMB
**门票 Ticket 60,000RMB (300x200元=6万）

== 参与我们 Participate ==

''演讲者''

欢迎在PostgreSQL的企业应用、架构设计、运维管理、应用开发等方面有心得的朋友，发表演讲。如果你有需要发表的内容，请联系 galylee@gmail.com

''志愿者''

请帮助我们宣传大会，在你的网站，或者在论坛，或者在其他大会，告诉大家PG全国大会的举行信息。

''赞助''

我们是非盈利的组织，单单凭我们的力量无法承担大会的会场等相关的运营费用，只有相关企业的赞助和参与才有可能有必要的资源在国内培养PostgreSQL社区的形成。更多的赞助，可以让我们能邀请到更重量级的嘉宾为我们演讲，可以让我们有个交流和参与的平台。需要赞助的包括：场地费用及宣传品、邀请国外嘉宾的机票及食宿、嘉宾的演讲资料印刷、各种小礼物、大会首日晚上的酒会等等。。

''捐赠''

我们是旨在推广PG在中国发展的非营利的团体，欢迎企业为PG社区进行捐赠，捐赠的款项将完全用于PG社区的推广，包括官方文档的翻译、社区网站的托管、PG的技术交流会、PG大会的运营等。

[http://wiki.postgresql.org/wiki/Pgconfchina2012-admin 大会组织]

[[Category:PostgreSQL Events]]

PgCon2012CanadaInCoreReplicationMeeting

2012-04-27T04:48:12Z

Dfetter: /* Attendees (alphabetical) */

= PostgreSQL In-Core Replication meeting, pgCon 2012 =

== Time and Place ==

Wednesday, May 16th, 6pm to 10pm

Ottawa somewhere, room TBA

== Agenda ==

Draft agenda follows. Please let me know of any contributions/changes to the agenda you have:

# Discussion of Multi-Master Theory (Simon)
# Demonstration of prototypes (Andres)
# Performance comparisons
# My use case (Keaton)
# Social Media use case (Simon)

Broad and general discussion throughout. Notes and actions will be taken. Volunteers for tasks welcome.

The meeting will be from 6pm to 10pm, with various forms of food and possibly a drink or two, sponsored by 2ndQuadrant.

== Attendees (alphabetical) ==

* Keaton Adams
* Josh Berkus (prefer vegetarian)
* David Fetter
* Dimitri Fontaine
* Andres Freund
* Jim Mlodgenski
* Jim Nasby (plus guest)
* Simon Riggs
...

Meeting limit about 20-25 people

=== Joining the Meeting ===

If you will be able to attend, please email Simon ([mailto:simon@2ndQuadrant.com simon@2ndQuadrant.com]) with the following:

* Your Name
* What pizza topping you like

and please come armed with detailed information about your future replication requirements.

Binary Replication Tutorial

2012-04-12T17:34:25Z

Dfetter: Made labels match URLs

Welcome to the new PostgreSQL 9 replication and standby databases guide. This new set of features implements possibly the longest awaited functionality in PostgreSQL's history. As a result, a lot of people are going to be trying to deploy standby databases for the first time, and find the process rather unintuitive. This guide is here to help.

'''Work in progress: only 40% complete'''

= 5 Minutes to Simple Replication =

This is the easiest way to set up replication between a master and standby. It requires shutting down the master; other methods are detailed later in this guide.

What we're going to do is shut down the master and copy the files we need over to the slave server, creating a cloned copy of the master. Because the master is shut down, we don't have to worry about changes being made to it.

Note: Both the '5 minutes' instructions and the '10 minutes' version which follows do not deal with the complications that arise with a database that uses tablespaces, specifically what to do about the pg_tblspc directory and its contents.

== Prerequisites ==

You must have the right setup to make this work:

* 2 servers with similar operating systems (e.g both Linux 64-bit).
* The same release of PostgreSQL 9.0 installed on both servers.
* PostgreSQL superuser shell access on both servers.
* Knowledge of how to start, stop and reload Postgres.
* PostgreSQL 9.0 running on Server1.
* A database created and loaded on Server1.
* A postgres user or root user who has network

See the full documentation for more information:

* [http://www.postgresql.org/docs/9.0/static/warm-standby.html 9.0 Replication Documentation]
* [http://www.postgresql.org/docs/9.1/static/warm-standby.html 9.1 Replication Documentation]

== Binary Replication in 6 Steps ==

This 6-step guide, and all of the examples in this tutorial, assume that you have a master server at 192.168.0.1 and a standby server at 192.168.0.2 and that your database and its configuration files are installed at /var/lib/postgresql/data. Replace those with whatever your actual server addresses and directories are.

1. Edit postgresql.conf on the master to turn on streaming replication. Change these settings:

listen_address = '*'
wal_level = hot_standby
max_wal_senders = 3

2. Edit pg_hba.conf on the master in order to let the standby connect.

host replication all 192.168.0.2/32 trust

3. Edit recovery.conf and postgresql.conf on the standby to start up replication and hot standby. First, in postgresql.conf, change this line:

hot_standby = on

Then create a file in the standby's '''data directory''' (which is often the same directory as postgresql.conf and pg_hba.conf, except on some Linux distributions such as Debian and Ubuntu), called recovery.conf, with the following lines:

standby_mode = 'on'
primary_conninfo = 'host=192.168.0.1'

4. Shutdown the master and copy the files. You want to copy most but not all files between the two servers, excluding the configuration files and the pg_xlog directory. An example rsync script would be:

rsync -av --exclude pg_xlog --exclude postgresql.conf data/* 192.168.0.2:/var/lib/postgresql/data/

5. Start the standby first, so that they can't get out of sync. (Messages will be logged about not being able to connect to the primary server, that's OK.)

6. Start the master.

== Starting Replication with only a Quick Master Restart ==

Is taking down the master for long enough to copy the files too long? Then you need the 10-minute version.

What we're going to do this time is similar to what we did before, cloning the database by copying the files from the master to the slave server. However, because the database is only going to be shut down for a short period of time, long enough to activate the changes in the configuration file, after we've copied the data files we will need to copy additional files so that the slave will be an up-to-date copy of the master.

So, we will tell the master we're running a backup, copy the data files (not quite the same set of files as before), tell the master the backup is complete, then copy the WAL files in the pg_xlog directory so that when the slave comes up it can make all the changes that were committed to the master database after the backup was started.

First, start with the same prerequisites as above.

1. Set the postgresql.conf variables the same in step (1) as above.

2. Don't close the file yet. You'll need to set two other variables which control the size of your write-ahead-log (WAL). The first is wal_keep_segments, the second is checkpoint_segments. Unless you've already done so, you're going to need to increase these, which is usually a good idea for performance anyway. You want the WAL to be big enough to not get used up in 15 or 20 minutes. If you don't have a clear idea of that, here's some reasonable values, based on how busy and how large your database is. Also, a database with large blob objects may require a much larger setting. Remember, these logs will take up disk space, so make sure that you have enough available - space requirements are below.

checkpoint_segments = 8
wal_keep_segments = 8
# light load 500MB

checkpoint_segments = 16
wal_keep_segments = 32
# moderately busy 1.5GB

checkpoint_segments = 64
wal_keep_segments = 128
# busy server 5GB

You don't ''have'' to increase checkpoint_segments in order to increase wal_keep_segments, but it's generally a good idea. Now save the file.

3. Edit pg_hba.conf as in (2) in the "Six Steps" above.

4. Now you need to restart the master. Given the interruption in service, you should probably plan this ahead.

5. Edit postgresql.conf and recovery.conf on the standby as in (3) above.

6. Now, we're going to need to copy the files from the master and start the standby. Unlike in the 6-step version, this needs to be done quickly or the standby will fail to sync and you'll need to try again. First step, you need to tell the master you're starting a backup (see below for a more detailed explanation of this). Log in to psql as the database superuser.

psql -U postgres
# select pg_start_backup('clone',true);

Note that the string you use as a backup label doesn't matter; use any string you want.

7. Now, quickly copy all the database files. This rsync is slightly different from the 6-step version:

rsync -av --exclude pg_xlog --exclude postgresql.conf --exclude postgresql.pid \
data/* 192.168.0.2:/var/lib/postgresql/data/

8. As soon as that's done you need to stop the backup on the master:

# select pg_stop_backup();

9. As soon as that completes, you need to quickly copy the WAL files from the master to the standby.

rsync -av data/pg_xlog 192.168.0.2:/var/lib/postgresql/data/

10. Now, start the standby.

If you've done this quickly enough, then the standby should catch up with the master and you should be replicating. If not, you'll get this message:

... which means you need to try again, possibly with checkpoint_segments and wal_keep_segments higher. If that still doesn't work, you're going to need to use the even more complex archiving method described below.

Now, the rest of the guide will explain how to deal with more complex situations, such as archive logs, handling security, and maintaining availability, failover and standby promotion.

= Introduction to Binary Replication =

Binary replication is also called "Hot Standby" and "Streaming Replication" which are two separate, but complimentary, features of PostgreSQL 9.0 and later. Here's some general information about how they work and what they are for.

== What Can You Do With Binary Replication? ==

* Have a simple and complete replica of your production database, preventing all but a couple seconds of data loss even under catastrophic circumstances.
* Load-balance between your read/write master server and multiple read-only servers.
* Run reporting or other long-running queries on a replica server, taking them off your main transaction-processing server.
* Replicate all DDL, including table and index changes, and even creating new databases.
* Replicate a hosted multi-tenant database, making no specific requirements for primary keys or database changes of your users.

== What Can't You Do With Binary Replication? ==

* Replicate a specific table, schema, or database. Binary replication is the entire Postgres instance (or "cluster").
* Multi-master replication. Multi-master binary replication is probably technically impossible.
* Replicate between different versions of PostgreSQL, or between different platforms.
* Set up replication without administration rights on the server. Sorry, working on it.
* Replicate data synchronously, guaranteeing zero data loss. But ... this is coming in PostgreSQL 9.1.

For the reasons above, we expect that Slony-I, Londiste, Bucardo, pgPool2 and other systems will continue to be used.

== Transaction Logs and Log Shipping ==

Users who are already familiar with the PostgreSQL transaction log and warm standby can skip this section.

An individual "instance", "server", or (confusingly) "cluster" of PostgreSQL (hereafter Server) consists of a single postmaster server process connected to a single initialized PostgreSQL data directory (PGDATA), which in turn contains several databases. Each running Server has a transaction log, located in the PGDATA/pg_xlog directory. This transaction log consists of binary snapshots of data, written to record synchronously each change to all databases' data, in case of unexpected shutdown of the database server (such as in a power failure). This ensures that data is not corrupted and no completed transaction is lost.

You can also use this log to allow a copy of the original database to replicate changes made to a master database. This was first implemented with the PITR feature in PostgreSQL 8.0, and is known as "log shipping". Log shipping is required for most forms of binary replication.

This log consists of 16MB segments full of new data pages (8K segments) of the database, and not of SQL statements. For this reason there is no before and after auditing possible via this log, as you cannot know exactly what has changed. Also, the log is treated as a buffer, being deleted as it is no longer needed for crash recovery. More importantly, the data page format of the log means that log segments can only be applied to a database which is binary-identical to the database which created the log.

== PITR, Warm Standby, Hot Standby, and Streaming Replication ==

For the rest of this tutorial, we will refer to the active read-write instance of the Server which generates transaction logs as the "Master" and the passive, read-only or offline instance (or instances) of the Server which receives transaction logs as the "Standby" (or "Standbys"). The term Master/Standby is equivalent to other terminology which may be used in the database industry, such as Master/Slave, Primary/Secondary or Primary/Replica.

=== PITR ===

In Point-In-Time Recovery (PITR), transaction logs are copied and saved to storage until needed. Then, when needed, the Standby server can be "brought up" (made active) and transaction logs applied, either stopping when they run out or at a prior point indicated by the administrator. PITR has been available since PostgreSQL version 8.0, and as such will not be documented here.

PITR is primarily used for database forensics and recovery. It is also useful when you need to back up a very large database, as it effectively supports incremental backups, which pg_dump does not.

=== Warm Standby ===

In Warm Standby, transaction logs are copied from the Master and applied to the Standby immediately after they are received, or at a short delay. The Standby is offline (in "recovery mode") and not available for any query workload. This allows the Standby to be brought up to full operation very quickly. Warm Standby has been available since version 8.3, and will not be fully documented here.

Warm Standby requires Log Shipping. It is primary used for database failover.

=== Hot Standby ===

Hot Standby is identical to Warm Standby, except that the Standby is available to run read-only queries. This offers all of the advantages of Warm Standby, plus the ability to distribute some business workload to the Standby server(s). Hot Standby by itself requires Log Shipping.

Hot Standby is used both for database failover, and can also be used for load-balancing. In contrast to Streaming Replication, it places no load on the master (except for disk space requirements) and is thus theoretically infinitely scalable. A WAL archive could be distributed to dozens or hundreds of servers via network storage. The WAL files could also easily be copied over a poor quality network connection, or by SFTP.

However, since Hot Standby replicates by shipping 16MB logs, it is at best minutes behind and sometimes more than that. This can be problematic both from a failover and a load-balancing perspective.

=== Streaming Replication ===

Streaming Replication improves either Warm Standby or Hot Standby by opening a network connection between the Standby and the Master database, instead of copying 16MB log files. This allows data changes to be copied over the network almost immediately on completion on the Master.

In Streaming Replication, the master and the standby have special processes called the walsender and walreceiver which transmit modified data pages over a network port. This requires one fairly busy connection per standby, imposing an incremental load on the master for each additional standby. Still, the load is quite low and a single master should be able to support multiple standbys easily.

Streaming replication does not require log shipping in normal operation. It may, however, require log shipping to start replication, and can utilize log shipping in order to catch up standbys which fall behind.

= How to Replicate =

== Cloning a Live Database ==

If your workload doesn't allow you to take the master down (and whose does?), things get a bit more complicated. You need to somehow take a "coherent snapshot" of the master, so that you don't have an inconsistent or corrupt database on the standby. Now, in some cases this can be done via filesystem snapshotting tools or similar tricks, but as that approach is tricky and platform-dependant, we're not going to cover it here.

Instead, we're going to cover the built-in method, which involves keeping a log of all changes applied to the database which happen during the copying process. The steps are essentially the same, regardless of whether you're planning to use just hot standby, streaming replication, or both. There are two parts:

* Cloning the database files
* Copying the archive logs

Unintuitive as it is, the latter needs to be set up first, so we're going to start with that.

== Setting Up Archiving On The Master ==

Archiving is the process of making an extra copy of each WAL file as it is completed. These log files then need to somehow be accessed by the standby. There are three basic ways to handle this, and you should decide in advance what method you're going to use:

# Manually
# Automatic file copying from master to standby using rsync or simiar
# Writing them to a common shared network file location

The first method is only appropriate if you're archiving logs only to jump-start streaming replication, and you have a fairly low-traffic database or the ability to stop all writes. The third method is probably the easiest to manage if you have an appropriate network share; it can even be used to support multiple standbys with some extra thought and scripting. All of these methods will be explained below.

This needs to be turned on on the master, which if it's never been done before may require a restart (sorry, working on it), and will certainly require a reload. You'll need to set the following parameters:

wal_level = hot_standby
archive_mode = on
archive_command = 'some command'

What archive command you use depends on which archiving approach you are taking, of course. Here are three examples of commands you might use. Note that you will need to create the "archive" directories.

# Manual: cp -f %p /var/lib/postgresql/data/archive/%f </dev/null
# Automatic Copy: rsync -a %p 192.168.0.2:/var/lib/pgsql/data/archive/%f
# Network Share: cp -f %p /shares/walarchive/archive/%f </dev/null

In these commands, %p is replace by postgres at invocation time with the full path and name of the WAL file, and %f with the name of the file alone. There are more escapes and parameters dealing with WAL archiving which will be detailed later in the tutorial. Note that, in real production, you are unlikely to want to use any commands as simple as the above. In general, you will want to have archive_command call an executable script which traps errors and can be disabled. Examples of such scripts are available in this tutorial.

Now, if archive_mode was originally "off" or if you had to change wal_level, you're going to need to restart the master (sorry, this will be fixed in a later version). If you just needed to change the archive_command, however, only a reload is required.

Once you've restarted or reloaded, check the master's logs to make sure archiving is working. If it's failing, the master will complain extensively. You might also check that archive log files are being created; run the command "SELECT pg_switch_xlog();" as the superuser to force a new log to be written.

== Setting Up Archiving on the Standby ==

The standby needs to be configured to consume logs. This is simpler than the master's setup, and doesn't really change no matter what archive copying strategy you're using.

== Recovery.conf ==

On the standby, replication configuration is controlled through a file called, for historical reasons, recovery.conf. If this file is present in PostgreSQL's data directory when PostgreSQL is started, that server will assume it is a standby and attempt to obey it. Generally, there is an example file installed with the other PostgreSQL shared docs. However, that example file covers all of the various replication options at once, so it's often simpler to write your own file, from scratch. Any change to recovery.conf requires a restart of the standby.

In recovery.conf, you need to add a command to copy the archived WAL files to the standby's on pg_xlog directory. This is the mirror image of the archive_command on the master. Generally, a simple cp command is sufficient:

restore_command = 'cp -f /var/lib/postgresql/data/archive/%f %p </dev/null'
restore_command = 'cp -f /shares/walarchive/%f %p </dev/null'

Again, you might want to use a simple shell script which traps error messages, and, importantly, deletes archive files which are no longer needed. If you will be doing only hot standby and not using streaming replication, you probably want to compile the pg_standby binary provided in PostgreSQL's additional modules or "contrib", and use it instead:

restore_command = 'pg_standby /shares/walarchive/%f %p %r'

More detail on pg_standby is in its documentation.

== Cloning a Snapshot of the Master ==

Once you have archiving working, you're ready to clone the master database. At this point, it's a simple process:

# As superuser, issue the command "SELECT pg_start_backup('backup');" on the master.
# Copy all of the database files to the standby.
# Start the standby database.
# Issue the command "SELECT pg_stop_backup();" on the master.

Of course, each of those steps deserves a little more elaboration. pg_start_backup and pg_stop_backup are special commands you issue on the master in order to create, hold open, and close, a "snapshot" which is how we make sure your copy of the database is not inconsistent. They also write special files to the archive log which tell the standby when it has a complete snapshot.

If you are using the "manual" method of synching the archive logs, immediately after step 4 you need to do one last rsync or copy of the archive logs to the standby.

When you're done with the cloning, you should see output similar to the below:

This means that you're up and replicating, and should now be able to run queries on the standby.

== Failing Over To The Standby ==

Of course, one of the major reasons to have a standby is in case something (planned or unplanned) causes the master server to shut down. Then you want to "fail over", or stop replication and change the standby to a full read-write master.

The recommended method is the same regardless of the type of replication or standby: via "trigger file". First, you need to set a configuration option in recovery.conf on the standby:

trigger_file = '/var/lib/postgresql/data/failover'

Then, when it's time to fail over, you just create an empty file with that name, such as by using the "touch" command. The standby will notice the file, attempt to apply any remaining WAL records or files it has received, and then switch to read-write or "master" mode. When this happens, you will see a message like this in the Postgres log:

PostgreSQL will also rename the recovery.conf file to recovery.done in order to prevent having the new master fail on restart. For this reason, the recovery.conf file should be owned by the same user which the server runs as (usually "postgres").

The alternative to using a trigger file is to failover manually, by deleting or renaming the recovery.conf file and restarting the standby. This method is inferior because it requires a restart which would interrupt any read-only connections to the standby currently in use.

In a high-availability system, the above activity should be managed automatically in order to avoid downtime. PostgreSQL itself supplies no tools to do this, but numerous third-party utilities such as "Linux heartbeat" are compatible with PostgreSQL replication.

It's important to prevent the original master from restarting after failover, lest you end up with a "split brain" problem and data loss. There is a substantial body of literature on this, and third-party tools, so we won't discuss them here at this time.

== Load Balancing ==

== Managing Archive Logs ==

== Tuning and Configuration of Binary Replication ==

== Monitoring Replication ==

[[Category:Replication]]

WWW FDW

2011-09-28T14:23:55Z

Dfetter: While it may be pronounced "shed-yule" in some parts of the world, it's spelled with a 'c'.

== Idea ==

Provide ability to work with data from web service using SQL.

== Benefits ==

* ability to select data from web service using different criterias (filters, sort, aggregation, other sql features);
* ability to join/union data from web service with other table data (probably output of another web service);
* export of data from web service into table view;
* common interface for any web service.

== Details ==

Will be implemented using [[Foreign data wrappers]] ([[SQL/MED]]).

Main complexity here is to build easy interface for wide range of web services. Main goal for this implementation will be [http://en.wikipedia.org/wiki/REST#RESTful_web_services RESTful] services.

=== Configuration ===

Each FDW will have following configuration options:
* uri - base URI for web service;
* uri_select - part of URI for selection command, default - "";
* uri_insert - part of URI for insert command, default - "" (reserved for future);
* uri_delete - part of URI for delete command, default - "" (reserved for future);
* uri_update - part of URI for update command, default - "" (reserved for future);
* uri_callback - callback for URI forming (in case it's not static);
* method_select - http method for select command, default value - "GET";
* method_insert - http method for insert command, default value - "PUT";
* method_delete - http method for delete command, default value - "DELETE";
* method_update - http method for update command, default value - "POST";
* request_serialize_callback - callback for forming request (for non standard cases, will be covered later);
* response_type - web service response content type, possible values:
** json - default value;
** xml
** yaml
** other
* response_deserialize_callback - callback for parsing responses of "other" type;
* response_iterate_callback - callback for extracting/iterating rows from response.

=== Commands ===

There is following correspondence between sql commands and http methods:
* SELECT - GET
* INSERT - PUT
* DELETE - DELETE
* UPDATE - POST

There are configurable options for correspondence above.

In the current version (postgres 9.1) there is no implementation for FDW INSERT/DELETE/UPDATE. But stuff related for INSERT/DELETE/UPDATE is reserved for future.

=== Request ===

Since all request parameters to web service are pairs (key,value), therefore default behavior for request preparation is:
pack pairs (column, value) from sql query as "column=pair". Operators differ from "=" will raise an error (if request_serialize_callback wasn't specified).

request_serialize_callback is designed for non standard request preparation (aliases for parameters, default parameters etc).

=== Response ===

In case response type is one of:
* json
* xml
* yaml
response will be parsed and response elements will be casted to postgres types.
If response_iterate_callback is specified it will be called from IterateForeignScan_function with result structure and bigint iterator.
Other way first array (if it has all elements of the same type/structure) will be returned (breadth-first search).

postgres has following data types which will cover needed data structures:
* strings/numbers/boolean/NULL;
* [http://www.postgresql.org/docs/9.1/interactive/arrays.html arrays];
* [http://www.postgresql.org/docs/9.1/interactive/rowtypes.html composite type].

In case of "other" response type response_deserialize_callback will be called. It's return value is array of result rows.

=== Callbacks ===

Example:
<pre>
CREATE OR REPLACE FUNCTION example_response_iterate_callback(e anyelement, idx bigint) RETURNS g AS $$
DECLARE
r g;
BEGIN
BEGIN
IF idx > array_length(e.items, 1) THEN
RETURN NULL;
END IF;
r.title := e.items[idx].title;
r.link := e.items[idx].link;
r.snippet := e.items[idx].snippet;
EXCEPTION
WHEN OTHERS THEN
RAISE EXCEPTION 'error occured, sqlstate: %', SQLSTATE;
END;
RETURN r;
END; $$ LANGUAGE PLPGSQL;
</pre>

Function is passed as FDW option:
<pre>
CREATE SERVER www_server FOREIGN DATA WRAPPER www_fdw OPTIONS (response_iterate_callback 'example_response_iterate_callback($1,$2)');
</pre>

Call to this function is implemented through [http://www.postgresql.org/docs/9.1/interactive/spi.html SPI].

=== Examples ===

Extension installation:
<pre>
-- Install the extension
CREATE EXTENSION www_fdw;

-- Create the foreign server, a pointer to the web service.
CREATE SERVER www_service FOREIGN DATA WRAPPER www_fdw
OPTIONS (uri 'URI', ...OTHER_PARAMETERS_HERE...);

CREATE USER MAPPING FOR current_user SERVER www_service;
</pre>

Example for [http://code.google.com/apis/customsearch/v1/overview.html google search API]:
<pre>
CREATE SERVER www_fdw_google_search_server FOREIGN DATA WRAPPER www_fdw
OPTIONS (uri 'https://www.googleapis.com/customsearch/v1?alt=qson&key=KEY');

CREATE FOREIGN TABLE www_fdw_google_search (
title text,
link text,
snippet text
) SERVER www_fdw_google_search_server;
</pre>

Queries examples:
<pre>
select title,snippet from www_fdw_google_search where q=’cat dog’ limit 1;
title | snippet
-----------------------------------------------------+-----------------------------------------------------------------------------------------
CatDog - Wikipedia, the free encyclopedia | CatDog is an American animated television series which first aired on April 4, 1998, ...

-- example of union with full text search:
select * from documents where body @@ plainto_tsquery('cat dog')
union
select title,snippet from www_fdw_google_search where q=’cat dog’ limit 1;
name | body
-----------------------------------------------------+-----------------------------------------------------------------------------------------
cat and dog | cat and dog set on a pavement
CatDog - Wikipedia, the free encyclopedia | CatDog is an American animated television series which first aired on April 4, 1998, ...
</pre>

Other interesting examples:
* different [http://code.google.com/labs/ google APIs]:
** [http://code.google.com/apis/books/ books];
** [http://code.google.com/apis/maps/documentation/javascript/ maps (geocoding for example)];
** [http://code.google.com/apis/socialgraph/docs/api.html social graph];
** ...
* [http://www.mediawiki.org/wiki/API:Opensearch wiki API];
* [https://dev.twitter.com/docs/api twitter];
* [http://developers.facebook.com/ facebook] / [https://developers.google.com/+/api/ google+] / other social nets;
* lot more.

== More ==

Besides providing specialized callbacks there is another way: building web service "in the middle", which translates formats. In simplest case it implements GET returning json array with row objects.

Central place is realization of extension core, which will be developed & QAed independently from any callback/web_services implementations. In this case it will be really easy to reuse this extension with minimum of coding for new services. From the other side, any complicated service can be handled with more complex callbacks.

== Schedule ==

'''TODO'''

== TODO ==

Foreign data wrappers

2011-09-21T05:49:40Z

Dfetter: /* SQL Databases Wrappers */

Events

2011-08-08T21:55:56Z

Dfetter: Added PGDay Porto Alegre

Events

2011-08-08T21:02:54Z

Dfetter: PG Conf Colombia is over.

Cyclic Tag System

2011-08-06T11:44:01Z

Dfetter: Cyclic Tag System

{{SnippetInfo|Cyclic Tag System|version=8.4|lang=SQL|category=Fun}}

This SQL query (requires PostgreSQL 8.4) forms a cyclic tag system, which is sufficient to demonstrate that SQL is Turing-complete. It is written entirely in SQL:2008-conformant SQL.

Thanks to Andrew (RhodiumToad) Gierth, who came up with the concept and wrote the code.

The productions are encoded in the table "p" as follows:
"iter" is the production number;
"rnum" is the index of the bit;
"tag" is the bit value.

This example uses the productions:
110 01 0000

The initial state is encoded in the non-recursive union arm, in this case just '1'

The (r.iter % n) subexpression encodes the number of productions, which can be greater than the size of table "p", because empty productions are not included in the table.

Parameters:
the content of "p"
the content of the non-recursive branch
the 3 in (r.iter % 3)

"p" encodes the production rules; the non-recursive branch is the initial state, and the 3 is the number of rules

The result at each level is a bitstring encoded as 1 bit per row, with rnum as the index of the bit number.

At each iteration, bit 0 is removed, the remaining bits shifted up one, and if and only if bit 0 was a 1, the content of the current production rule is appended at the end of the string.

<source lang="sql">
WITH RECURSIVE
p(iter,rnum,tag) AS (
VALUES (0,0,1),(0,1,1),(0,2,0),
(1,0,0),(1,1,1),
(2,0,0),(2,1,0),(2,2,0),(2,3,0)
),
r(iter,rnum,tag) AS (
VALUES (0,0,1)
UNION ALL
SELECT r.iter+1,
CASE
WHEN r.rnum=0 THEN p.rnum + max(r.rnum) OVER ()
ELSE r.rnum-1
END,
CASE
WHEN r.rnum=0 THEN p.tag
ELSE r.tag
END
FROM
r
LEFT JOIN p
ON (r.rnum=0 and r.tag=1 and p.iter=(r.iter % 3))
WHERE
r.rnum>0
OR p.iter IS NOT NULL
)
SELECT iter, rnum, tag
FROM r
ORDER BY iter, rnum;
</source>

Table partitioning

2011-07-26T15:40:26Z

Dfetter: /* Oracle-Style */

= Background =

== Status Quo ==
Currently we allow the user to create arbitrary nested tables with arbitrary constraints and then the planner tries to detect at run-time which child tables are candidates for the query. See [http://www.postgresql.org/docs/current/interactive/ddl-partitioning.html PostgreSQL Partitioning] for details.

=== Resolved Issues ===
* SELECT, UPDATE, DELETE (in 8.2) : They can be handled with constraint_exclusion.
* TRUNCATE (in 8.4) : TRUNCATE for a parent table is expanded into child tables.
* ANALYZE (in 9.0) : {{MessageLink|20091229201145.CF641753FB7@cvs.postgresql.org|ANALYZE to compute such stats for tables that have subclasses}}
* MAX()/MIN() (in 9.1) : Smarter partition detection.

=== Limitations ===
* We never exclude the parent table
* We don't handle INSERTs on the parent table
* It requires a lot of manual work to set it up

== Overviews of Project Goals ==
* [[:Image:Partitioning Requirements.pdf | Partitioning Requirements document from Simon Riggs]]
* [[PgCon 2008 Developer Meeting#Partitioning_Roadmap|PGCon 2008 Developer meeting roadmap]]

=== List discussions ===

* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00375.php <nowiki>Auto creation of Partitions</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00151.php <nowiki>Re: Auto Partitioning Patch - WIP version 1</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00028.php <nowiki>Dynamic Partitioning using Segment Visibility Maps</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00248.php <nowiki>Named vs Unnamed Partitions</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00387.php <nowiki>Storage Model for Partitioning</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00413.php <nowiki>Declarative partitioning grammar</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01097.php Auto-Partitioning patch discussion]
* [http://archives.postgresql.org/pgsql-hackers/2009-03/msg00897.php Partitioning feature]
* [http://archives.postgresql.org/pgsql-performance/2009-05/msg00005.php Transparent table partitioning in future version of PG?]
* [http://archives.postgresql.org/message-id/1247564358.11347.1308.camel@ebony.2ndQuadrant Comments on automatic DML routing and explicit partitioning subcommands]
* [http://archives.postgresql.org/pgsql-hackers/2009-10/msg01831.php Patch for automated partitioning]
* [http://archives.postgresql.org/message-id/20091112195450.A967.52131E4D@oss.ntt.co.jp Syntax for partitioning]
* [http://archives.postgresql.org/message-id/4AFADD6A.9070002@asterdata.com Partitioning support for COPY]
* [http://archives.postgresql.org/pgsql-hackers/2010-07/msg01519.php Scalability of the planner with non trivial number of partitions]

== Possible Directions ==

=== Oracle-Style ===
Allow users to declare their intention with partitioned tables. Ie, declare what the partition key is and what range or values are covered by each partition.

I think this would mean two new types of relation. One "meta-table" that acts like a view, in that it doesn't have an attached filenode. It would also have some kind of meta data about the partition key but no view definition, it would act like parent tables in nested table structure do now. The other would be "partition" which would be a separate namespace from tables and would have attached information about what values of the partition key it covered.

Pros:

* Makes it more reasonable to handle inserts automatically since the structure is explicit and doesn't require making logical deductions.
* More idiot-proof, ie you can't set up nonsensical combinations of constraints.
* Consistent with other databases and DBA expectations.

Cons:

* Less flexible, you can't set up arbitrary non-traditional structures such as having some data in the parent table or having extra columns in some children.

Background:
* [http://download-east.oracle.com/docs/cd/B13789_01/server.101/b10759/statements_7002.htm#i2129707 Oracle CREATE TABLE syntax]
* [http://download-east.oracle.com/docs/cd/B13789_01/server.101/b10736/parpart.htm Partitioning in Oracle 10g]
* [http://download-east.oracle.com/docs/cd/B13789_01/server.101/b10739/partiti.htm#i1006820 Partition management in Oracle 10g]
* [http://www.oracle.com/technetwork/articles/sql/11g-partitioning-084209.html Partition management in Oracle 11g including interval partitions]
* [http://dev.mysql.com/doc/refman/5.1/en/partitioning.html MySQL partitioning]

=== Trigger-based ===
First attempts to support auto-partitioning have been made using triggers.
* avoid specific languages such as pgpsql that requires 'CREATE LANGUAGE'
* performance of C trigger 4 to 5 times faster than pgpsql
* insert/copy returns 0 rows when all rows have been routed by trigger from master to child tables
* chaining triggers allow tunable behavior in case of rows not matching any partition: add an error trigger, move to an overflow table, create new partitions dynamically
* constraint_exclusion does not work well with prepared statements. It might possible to convert CHECKs to One-Time Filter plan nodes if the condition is a variable.

= Active Work In Progress =

== Syntax ==
Syntax is proposed at "[https://commitfest.postgresql.org/action/patch_view?id=207 Syntax for partitioning]", [https://commitfest.postgresql.org/action/patch_view?id=266 second version]. The syntax resembles [[Oracle]] and [[MySQL]]. See also [[Todo#Administration]] (Simplify ability to create partitioned tables).

-- create partitioned table and child partitions at once.
CREATE TABLE parent (...)
PARTITION BY [ RANGE | LIST ] ( key ) [ opclass ]
[ (
PARTITION child
{
VALUES LESS THAN { ... | MAXVALUE } -- for RANGE
| VALUES [ IN ] ( { ... | DEFAULT } ) -- for LIST
}
[ WITH ( ... ) ] [ TABLESPACE tbs ]
[, ...]
) ] ;

-- add a partition key to a table.
ALTER TABLE parent PARTITION BY [ RANGE | LIST ] ( key ) [ opclass ] [ (...) ] ;

-- create a new partition on a partitioned table.
CREATE PARTITION child ON parent VALUES ... ;

-- add a table as a partition.
ALTER TABLE parent ATTACH PARTITION child VALUES ... ;

-- Remove a partition as a normal table.
ALTER TABLE parent DETACH PARTITION child ;

== Internal representation ==
On-disk structure is included in the "Syntax for partitioning" patch.
On-memory structure will be proposed in a future patch

=== On-disk structure ===
A new system table "pg_partition" added.
Partition keys are stored in it.

CREATE TABLE pg_catalog.pg_partition
(
partrelid oid NOT NULL, -- partitioned table oid
partopclass oid NOT NULL, -- operator class to compare keys
partkind "char" NOT NULL, -- kind of partition: RANGE or LIST
partkey text, -- partition key expression

PRIMARY KEY (partrelid),
FOREIGN KEY (partrelid) REFERENCES pg_class (oid),
FOREIGN KEY (partopclass) REFERENCES pg_opclass (oid)
)
WITHOUT OIDS ;

A new column "inhvalues" are added into pg_inherits.
Partition values for each partition are stored in it.

ALTER TABLE pg_class.pg_inherits ADD COLUMN inhvalues anyarray ;

* RANGE partition has an upper value of the range in partkey.
* LIST partition has an array with multiple elements in partkey.
* An overflow partition has an empty array in partkey.
* A normal inherited table has a NULL in partkey.

=== On-memory structure ===
A cached list of partitions are sorted by partition values and stored in the relcache for the parent table. Changes to the partitions would need to invalidate parent caches to ensure the cache is accurately maintained.

== Operations ==
=== INSERT ===
INSERT TRIGGERs will be replaced with specialized tuple-routing feature using on-memory structure. Tuples will be routed in O(log N). It also solve "0 row affected" problem in INSERT TRIGGERs.

=== SELECT, UPDATE, DELETE ===
CHECK constraints continue to be used for a while.

It would be improved using on-memory structure; instead of CHECK constraints for each child tables, we can use a sorted list in the parent table. Constraint exclusion can be in O(log N) order instead of O(N) of now.

=== VACUUM, CLUSTER, REINDEX ===
We don't expand those commands for now, but they might have to be expanded like as TRUNCATE.

= Future improvements =
They are hard to fix in 9.0, but should continue to be improved in the future releases.

=== Syntax ===
* Support SPLIT and MERGE for existing partitions. See also [http://archives.postgresql.org/pgsql-hackers/2009-10/msg01831.php Kedar's patch]
* Support UPDATE of partition keys and values.
* Support adding a partition between existing partitions. It requires SPLIT feature.
* Support sub-partitions.
* Support some partition kinds for GIS types. For example, "PARTITION BY GIST" holds partition keys as a GiST tree in on-memory structure.
* Support HASH partitions. Each partition could be a FOREIGN TABLE in [[SQL/MED]]. In other words, it is [[PL/Proxy]] integration.
* Support CREATE TABLE AS -- CREATE TABLE tbl PARTITION BY ... AS SELECT ...;

=== Executor ===
* SELECT FOR SHARE/UPDATE for parent tables.
* Prepared statements that uses partition keys in place holders.
** An idea is to convert check constraints into One-Time_Filter [http://archives.postgresql.org/message-id/20081013172100.87A1.52131E4D@oss.ntt.co.jp]
* Unique constraint over multiple partitions, when each partition has a unique index on set/superset of partition keys
* Unique constraints over multiple partitions in the general case (typically called as "global index").

=== Planner ===
* Optimization for min/max, LIMIT + ORDER BY, GROUP BY on partition keys.
* Optimization when constraint exclusion are used with stable or volatile functions. It is a very common case that the partition key is timestamp and compared with now().
* Join optimization for two partitioned tables.

[[Category:Table partitioning]]

Table partitioning

2011-06-21T18:56:12Z

Dfetter: /* Resolved Issues */

= Background =

== Status Quo ==
Currently we allow the user to create arbitrary nested tables with arbitrary constraints and then the planner tries to detect at run-time which child tables are candidates for the query. See [http://www.postgresql.org/docs/current/interactive/ddl-partitioning.html PostgreSQL Partitioning] for details.

=== Resolved Issues ===
* SELECT, UPDATE, DELETE (in 8.2) : They can be handled with constraint_exclusion.
* TRUNCATE (in 8.4) : TRUNCATE for a parent table is expanded into child tables.
* ANALYZE (in 9.0) : {{MessageLink|20091229201145.CF641753FB7@cvs.postgresql.org|ANALYZE to compute such stats for tables that have subclasses}}
* MAX()/MIN() (in 9.1) : Smarter partition detection.

=== Limitations ===
* We never exclude the parent table
* We don't handle INSERTs on the parent table
* It requires a lot of manual work to set it up

== Overviews of Project Goals ==
* [[:Image:Partitioning Requirements.pdf | Partitioning Requirements document from Simon Riggs]]
* [[PgCon 2008 Developer Meeting#Partitioning_Roadmap|PGCon 2008 Developer meeting roadmap]]

=== List discussions ===

* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00375.php <nowiki>Auto creation of Partitions</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00151.php <nowiki>Re: Auto Partitioning Patch - WIP version 1</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00028.php <nowiki>Dynamic Partitioning using Segment Visibility Maps</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00248.php <nowiki>Named vs Unnamed Partitions</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00387.php <nowiki>Storage Model for Partitioning</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00413.php <nowiki>Declarative partitioning grammar</nowiki>]
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01097.php Auto-Partitioning patch discussion]
* [http://archives.postgresql.org/pgsql-hackers/2009-03/msg00897.php Partitioning feature]
* [http://archives.postgresql.org/pgsql-performance/2009-05/msg00005.php Transparent table partitioning in future version of PG?]
* [http://archives.postgresql.org/message-id/1247564358.11347.1308.camel@ebony.2ndQuadrant Comments on automatic DML routing and explicit partitioning subcommands]
* [http://archives.postgresql.org/pgsql-hackers/2009-10/msg01831.php Patch for automated partitioning]
* [http://archives.postgresql.org/message-id/20091112195450.A967.52131E4D@oss.ntt.co.jp Syntax for partitioning]
* [http://archives.postgresql.org/message-id/4AFADD6A.9070002@asterdata.com Partitioning support for COPY]
* [http://archives.postgresql.org/pgsql-hackers/2010-07/msg01519.php Scalability of the planner with non trivial number of partitions]

== Possible Directions ==

=== Oracle-Style ===
Allow users to declare their intention with partitioned tables. Ie, declare what the partition key is and what range or values are covered by each partition.

I think this would mean two new types of relation. One "meta-table" that acts like a view, in that it doesn't have an attached filenode. It would also have some kind of meta data about the partition key but no view definition, it would act like parent tables in nested table structure do now. The other would be "partition" which would be a separate namespace from tables and would have attached information about what values of the partition key it covered.

Pros:

* Makes it more reasonable to handle inserts automatically since the structure is explicit and doesn't require making logical deductions.
* More idiot-proof, ie you can't set up nonsensical combinations of constraints.
* Consistent with other databases and DBA expectations.

Cons:

* Less flexible, you can't set up arbitrary non-traditional structures such as having some data in the parent table or having extra columns in some children.

Background:
* [http://download-east.oracle.com/docs/cd/B13789_01/server.101/b10759/statements_7002.htm#i2129707 Oracle CREATE TABLE syntax]
* [http://download-east.oracle.com/docs/cd/B13789_01/server.101/b10736/parpart.htm Partitioning in Oracle 10g]
* [http://download-east.oracle.com/docs/cd/B13789_01/server.101/b10739/partiti.htm#i1006820 Partition management in Oracle 10g]
* [http://www.oracle.com/technology/obe/11gr1_db/bidw/partition/partition.htm Partition management in Oracle 11g including interval partitions]
* [http://dev.mysql.com/doc/refman/5.1/en/partitioning.html MySQL partitioning]

=== Trigger-based ===
First attempts to support auto-partitioning have been made using triggers.
* avoid specific languages such as pgpsql that requires 'CREATE LANGUAGE'
* performance of C trigger 4 to 5 times faster than pgpsql
* insert/copy returns 0 rows when all rows have been routed by trigger from master to child tables
* chaining triggers allow tunable behavior in case of rows not matching any partition: add an error trigger, move to an overflow table, create new partitions dynamically
* constraint_exclusion does not work well with prepared statements. It might possible to convert CHECKs to One-Time Filter plan nodes if the condition is a variable.

= Active Work In Progress =

== Syntax ==
Syntax is proposed at "[https://commitfest.postgresql.org/action/patch_view?id=207 Syntax for partitioning]", [https://commitfest.postgresql.org/action/patch_view?id=266 second version]. The syntax resembles [[Oracle]] and [[MySQL]]. See also [[Todo#Administration]] (Simplify ability to create partitioned tables).

-- create partitioned table and child partitions at once.
CREATE TABLE parent (...)
PARTITION BY [ RANGE | LIST ] ( key ) [ opclass ]
[ (
PARTITION child
{
VALUES LESS THAN { ... | MAXVALUE } -- for RANGE
| VALUES [ IN ] ( { ... | DEFAULT } ) -- for LIST
}
[ WITH ( ... ) ] [ TABLESPACE tbs ]
[, ...]
) ] ;

-- add a partition key to a table.
ALTER TABLE parent PARTITION BY [ RANGE | LIST ] ( key ) [ opclass ] [ (...) ] ;

-- create a new partition on a partitioned table.
CREATE PARTITION child ON parent VALUES ... ;

-- add a table as a partition.
ALTER TABLE parent ATTACH PARTITION child VALUES ... ;

-- Remove a partition as a normal table.
ALTER TABLE parent DETACH PARTITION child ;

== Internal representation ==
On-disk structure is included in the "Syntax for partitioning" patch.
On-memory structure will be proposed in a future patch

=== On-disk structure ===
A new system table "pg_partition" added.
Partition keys are stored in it.

CREATE TABLE pg_catalog.pg_partition
(
partrelid oid NOT NULL, -- partitioned table oid
partopclass oid NOT NULL, -- operator class to compare keys
partkind "char" NOT NULL, -- kind of partition: RANGE or LIST
partkey text, -- partition key expression

PRIMARY KEY (partrelid),
FOREIGN KEY (partrelid) REFERENCES pg_class (oid),
FOREIGN KEY (partopclass) REFERENCES pg_opclass (oid)
)
WITHOUT OIDS ;

A new column "inhvalues" are added into pg_inherits.
Partition values for each partition are stored in it.

ALTER TABLE pg_class.pg_inherits ADD COLUMN inhvalues anyarray ;

* RANGE partition has an upper value of the range in partkey.
* LIST partition has an array with multiple elements in partkey.
* An overflow partition has an empty array in partkey.
* A normal inherited table has a NULL in partkey.

=== On-memory structure ===
A cached list of partitions are sorted by partition values and stored in the relcache for the parent table. Changes to the partitions would need to invalidate parent caches to ensure the cache is accurately maintained.

== Operations ==
=== INSERT ===
INSERT TRIGGERs will be replaced with specialized tuple-routing feature using on-memory structure. Tuples will be routed in O(log N). It also solve "0 row affected" problem in INSERT TRIGGERs.

=== SELECT, UPDATE, DELETE ===
CHECK constraints continue to be used for a while.

It would be improved using on-memory structure; instead of CHECK constraints for each child tables, we can use a sorted list in the parent table. Constraint exclusion can be in O(log N) order instead of O(N) of now.

=== VACUUM, CLUSTER, REINDEX ===
We don't expand those commands for now, but they might have to be expanded like as TRUNCATE.

= Future improvements =
They are hard to fix in 9.0, but should continue to be improved in the future releases.

=== Syntax ===
* Support SPLIT and MERGE for existing partitions. See also [http://archives.postgresql.org/pgsql-hackers/2009-10/msg01831.php Kedar's patch]
* Support UPDATE of partition keys and values.
* Support adding a partition between existing partitions. It requires SPLIT feature.
* Support sub-partitions.
* Support some partition kinds for GIS types. For example, "PARTITION BY GIST" holds partition keys as a GiST tree in on-memory structure.
* Support HASH partitions. Each partition could be a FOREIGN TABLE in [[SQL/MED]]. In other words, it is [[PL/Proxy]] integration.
* Support CREATE TABLE AS -- CREATE TABLE tbl PARTITION BY ... AS SELECT ...;

=== Executor ===
* SELECT FOR SHARE/UPDATE for parent tables.
* Prepared statements that uses partition keys in place holders.
** An idea is to convert check constraints into One-Time_Filter [http://archives.postgresql.org/message-id/20081013172100.87A1.52131E4D@oss.ntt.co.jp]
* Unique constraint over multiple partitions, when each partition has a unique index on set/superset of partition keys
* Unique constraints over multiple partitions in the general case (typically called as "global index").

=== Planner ===
* Optimization for min/max, LIMIT + ORDER BY, GROUP BY on partition keys.
* Optimization when constraint exclusion are used with stable or volatile functions. It is a very common case that the partition key is timestamp and compared with now().
* Join optimization for two partitioned tables.

[[Category:Table partitioning]]

PgCon 2011 PL Summit

2011-05-19T20:21:56Z

Dfetter:

What: PL Summit

Where: PgCon, Ottawa

Date: Saturday May 21, 2011

Time: 9:30am - 5pm

Room: DMS 1110

= Tentative Agenda =

9:30am: Introductions

10am: State of PLs

* Jan Urbański - PL/Python
* Alexey Klyukin - PL/PHP and PL/Perl
* Luis Carvalho - PL/Lua
* Tim Child - PL/OpenCL
* David Fetter - PL/Parrot

10:30am: PLs as Extensions - Dimitri Fontaine

11:00am: Discussion of documentation for PL supported features

http://wiki.postgresql.org/wiki/PL_Matrix

http://wiki.postgresql.org/wiki/PL_Features_Matrix

11:30am: Discussion of improvements to PostgreSQL PL interface

12:30am: Break for lunch

1:30pm-5pm: Small groups for detailed discussion and hacking

= Related wiki pages =

[[PL_Matrix]]

[[PL_Features_Matrix]]

= Attendees =
Selena Deckelmann

Leon Starr

Pavel Stehule

Dimitri Fontaine

David E. Wheeler

David Fetter

Aaron Thul

Alexey Klyukin

Brian Decker

Jan Urbański

Steve Singer

Alvaro Herrera

Jan Wieck

Heikki Linnakangas

PgCon 2011 Developer Meeting

2011-05-17T21:40:08Z

Dfetter: /* Proposed Agenda Items */

A meeting of the most active PostgreSQL developers and senior figures from PostgreSQL-developer-sponsoring companies is being planned for Wednesday 18th May, 2010 near the University of Ottawa, prior to pgCon 2011. 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 refreshments/food sponsored by EnterpriseDB. Other companies sponsored attendance for their developers.

== Time & Location ==

The meeting will be from 9AM to 5PM, and will be in the "Albion B" room at:

Novotel Ottawa
33 Nicholas Street
Ottawa
Ontario
K1N 9M7

Food and drink will be provided throughout the day, including breakfast from 8AM.

[http://maps.google.ca/maps?f=q&source=s_q&hl=en&geocode=&q=novotel+ottawa&aq=&sll=49.891235,-97.15369&sspn=36.237851,79.013672&ie=UTF8&hq=novotel+ottawa&hnear=&ll=45.421528,-75.683699&spn=0.036869,0.077162&z=14&iwloc=A&layer=c&cbll=45.425741,-75.689638&panoid=Z4FUGnkZkdHAOkIxyjjS9Q&cbp=12,25.83,,0,-0.6 View on Google Maps]

== Attendees ==

The following people have RSVPed to the meeting:

* Oleg Bartunov
* Josh Berkus
* Jeff Davis
* Selena Deckelmann
* Andrew Dunstan
* David Fetter
* Marc Fournier
* Dimitri Fontaine
* Stephen Frost
* Kevin Grittner
* Robert Haas
* Magnus Hagander
* Alvaro Herrera
* Tatsuo Ishii
* Marko Kreen
* KaiGai Kohei
* Tom Lane
* Heikki Linnakangas
* Fuji Masao
* Bruce Momjian
* Dave Page
* Simon Riggs
* Teodor Sigaev
* Greg Smith
* Greg Stark
* Koichi Suzuki
* Robert Treat
* David Wheeler
* Mark Wong

== Proposed Agenda Items ==

Please list proposed agenda items here:

* Review of the move from CVS to GIT (Dave Page)
* Build and Test Automation (David Fetter)
* SELinux/PG Update and what-about-RLS? (Stephen Frost, KaiGai Kohei)
* What to do about MaxAllocSize? (Stephen Frost)
* Improving logging (Stephen Frost, David Fetter)
* Changes to the Wire Protocol (David Fetter)
* Slave-only based backups (Robert Treat)
* Authorization issues (Alvaro Herrera)
* Resource control (Simon Riggs)
* User Defined Daemons (Simon Riggs)
* Streaming SRFs and FDW WHERE clauses (Simon Riggs)
* Schedule for 9.2 Development (Robert Haas)
* Database Federation support (Koichi Suzuki)
* Report from prior day's Clustering Summit (Josh Berkus)
* Managing release schedules and patch submission processes (Dave Page)

== Agenda ==

{| border="1" cellpadding="4" cellspacing="0"
!Time
!Item
!Presenter
|- style="font-style:italic;background-color:lightgray;"
|08:00
|Breakfast
|
|-
|08:45 - 09:00
|Welcome and introductions
|Dave Page
|-
|09:00 - 09:15
|Review of the move from CVS to GIT
|Dave Page
|-
|09:15 - 09:45
|Build and test automation
|David Fetter
|-
|09:45 - 10:15
|SELinux/PG Update, and what to do about RLS? [http://sepgsql.googlecode.com/files/pgcon2010-developer-meeting-kaigai-handsout.pdf (handout)]
|Stephen Frost, KaiGai Kohei
|-
|10:15 - 10:30
|What to do about MaxAllocSize?
|Stephen Frost
|-
|- style="font-style:italic;background-color:lightgray;"
|10:30 - 10:45
|Coffee break
|
|-
|10:45 - 11:00
|Schedule for 9.2 development
|Robert Haas
|-
|11:00 - 11:20
|Report from prior day's Clustering Summit
|Josh Berkus
|-
|11:20 - 11:40
|Improving logging
|Stephen Frost, David Fetter
|-
|11:40 - 12:00
|Slave-only based backups
|Robert Treat
|-
|12:00 - 12:30
|Resource control
|Simon Riggs
|- style="font-style:italic;background-color:lightgray;"
|12:30 - 13:30
|Lunch
|
|-
|13:30 - 14:00
|Authorisation issues
|Alvaro Herrera
|-
|14:00 - 14:30
|DBT-2 I/O performance
|Koichi Suzuki
|-
|14:30 - 15:00
|Streaming SRFs and FDW WHERE clauses
|Simon Riggs
|- style="font-style:italic;background-color:lightgray;"
|15:00 - 15:15
|Tea break
|
|-
|15:15 - 15:45
|Database federation support
|Koichi Suzuki
|-
|15:45 - 16:15
|User defined daemons
|Simon Riggs
|-
|16:15 - 16:45
|Managing release schedules and patch submission processes
|Dave Page
|-
|16:45 - 17:00
|Any other business/group photo
|Dave Page
|- style="font-style:italic;background-color:lightgray;"
|17:00
|Finish
|
|}

PostgreSQL Release Support Policy

2011-04-27T19:10:28Z

Dfetter: notes about 8.1 on windows no longer relevant.

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
|}

PgCon 2011 Developer Meeting

2011-04-22T14:14:51Z

Dfetter: /* Attendees */

PgCon 2011 Developer Meeting

2011-03-07T18:26:59Z

Dfetter: /* Proposed Agenda Items */

PgCon 2011 Developer Meeting

2011-03-03T20:50:18Z

Dfetter: /* Proposed Agenda Items */

PgCon 2011 Developer Meeting

2011-03-03T20:36:07Z

Dfetter: /* Attendees */

PGDay Europe 2010 rideshare

2010-11-28T22:54:41Z

Dfetter: /* Departure from Stuttgart Airport (STR) */

This page is for registering your arrival to and departure from Stuttgart for PGDay Europe 2010, in case you want to share a ride with someone or just meet up for some company. Just put your arrival information down, and then coordinate with whomever arrives around the same time.

''There is no official coordination activity, we just provide this wiki page for people to register their own information.''

== Arriving at Stuttgart Airport (STR) ==
{|
!!|Day||Time||Flight||Name/contact info
|-
|Sunday (Dec 5th)||14:40||BA0920||Thom Brown||thom@linux.com
|-
|Sunday (Dec 5th)||17:15||UA9242||David Fetter||davidfetter@postgresql.org
|-
|Sunday (Dec 5th)||21:00||AF5586||Jean-Christophe Arnu || jca@postgresql.fr
|-
|Monday (Dec 6th)||09:25||AB6611||Andreas Zickel||zickel@hesgdv.de
|-
|Monday (Dec 6th)||09:25||AB6611||Christopher Dove||dove@hesgdv.de
|}

== Arriving at Stuttgart Main Station ==

{|
!!|Day||Time||Train||Name/contact info
|-
|Monday (Dec 6th)||09:08||ICE 591||Hartmut Holzgraefe & Susanne Ebrecht: <hartmut@php.net or miracee@web.de> +49-172-2707759 or call Susanne (Magnus should have the number)
|-
|Sunday (Dec 5th)||14:08||ICE 517||Giuseppe Maxia (datacharmer AT gmail dot com)
|}

== Arriving at Frankfurt Airport (FRA) ==
{|
!!|Day||Time||Flight||Name/contact info
|-
|Sunday (Dec 5th)||15:05||LH849||Heikki Linnakangas (heikki@enterprisedb.com, +358405226830)
|-
|Sunday (Dec 5th)||10:05, Frankfurt-Terminal 2 (FRA)||EI0650||Peter Geoghegan (peter.geoghegan86@gmail.com, +353 863271976)
|-
|Sunday (Dec 5th)||11:15, Frankfurt-Terminal 2 (FRA)||AZ400||Giuseppe Maxia (datacharmer AT gmail dot com)
|-
|Saturday (Dec 4th)||06:20, Frankfurt-Terminal (FRA)||US700||Bruce Momjian (bruce@momjian.us)
|}

== Departure from Stuttgart Airport (STR) ==
{|
!!|Day||Time||Flight||Name/contact info
|-
|Thursday (Dec 9th)||07:00||AF5581||Jean-Christophe Arnu ||jca@postgresql.fr
|-
|Thursday (Dec 9th)||09:20||LH2143||David Fetter ||davidfetter@postgresql.org
|-
|Thursday (Dec 9th)||15:15||AB6612||Andreas Zickel||zickel@hesgdv.de
|-
|Thursday (Dec 9th)||15:15||AB6612||Christopher Dove||dove@hesgdv.de
|-
|Thursday (Dec 9th)||15:30||BA0919||Thom Brown||thom@linux.com
|-
|Friday (Dec 10th)||11:50||SK658||Magnus Hagander||magnus@hagander.net
|}

== Departure from Stuttgart Main Station ==
{|
!!|Day||Time||Train||Name/contact info
|-
|Wednesday (Dec 8th)||16:10||EC 144||Hartmut Holzgraefe & Susanne Ebrecht: <hartmut@php.net>
|-
|Thursday (Dec 9th)||05:51||ICE 616 || Giuseppe Maxia (datacharmer AT gmail dot com)
|}

== Departure from Frankfurt Airport (FRA) ==
{|
!!|Day||Time||Flight||Name/contact info
|-
|Thursday (Dec 9th)||10:50, Frankfurt-Terminal 2 (FRA)||EI0651||Peter Geoghegan (peter.geoghegan86@gmail.com, +353 863271976)
|-
|Thursday (Dec 9th)||09:40, Frankfurt-Terminal 2 (FRA)||AZ413||Giuseppe Maxia (datacharmer at gmail dot com)
|}

== Other ==
* I'm heading to Erfurt on Thursday (Dec 9th). Anyone going to that direction that could give me a ride? - Heikki Linnakangas (heikki@enterprisedb.com, +358405226830)

PGDay Europe 2010 rideshare

2010-11-28T18:58:52Z

Dfetter: /* Arriving at Stuttgart Airport (STR) */

This page is for registering your arrival to and departure from Stuttgart for PGDay Europe 2010, in case you want to share a ride with someone or just meet up for some company. Just put your arrival information down, and then coordinate with whomever arrives around the same time.

''There is no official coordination activity, we just provide this wiki page for people to register their own information.''

== Arriving at Stuttgart Airport (STR) ==
{|
!!|Day||Time||Flight||Name/contact info
|-
|Sunday (Dec 5th)||14:40||BA0920||Thom Brown||thom@linux.com
|-
|Sunday (Dec 5th)||17:15||UA9242||David Fetter||davidfetter@postgresql.org
|-
|Sunday (Dec 5th)||21:00||AF5586||Jean-Christophe Arnu || jca@postgresql.fr
|-
|Monday (Dec 6th)||09:25||AB6611||Andreas Zickel||zickel@hesgdv.de
|-
|Monday (Dec 6th)||09:25||AB6611||Christopher Dove||dove@hesgdv.de
|}

== Arriving at Stuttgart Main Station ==

{|
!!|Day||Time||Train||Name/contact info
|-
|Monday (Dec 6th)||09:08||ICE 591||Hartmut Holzgraefe & Susanne Ebrecht: <hartmut@php.net or miracee@web.de> +49-172-2707759 or call Susanne (Magnus should have the number)
|-
|Sunday (Dec 5th)||14:08||ICE 517||Giuseppe Maxia (datacharmer AT gmail dot com)
|}

== Arriving at Frankfurt Airport (FRA) ==
{|
!!|Day||Time||Flight||Name/contact info
|-
|Sunday (Dec 5th)||15:05||LH849||Heikki Linnakangas (heikki@enterprisedb.com, +358405226830)
|-
|Sunday (Dec 5th)||10:05, Frankfurt-Terminal 2 (FRA)||EI0650||Peter Geoghegan (peter.geoghegan86@gmail.com, +353 863271976)
|-
|Sunday (Dec 5th)||11:15, Frankfurt-Terminal 2 (FRA)||AZ400||Giuseppe Maxia (datacharmer AT gmail dot com)
|-
|Saturday (Dec 4th)||06:20, Frankfurt-Terminal (FRA)||US700||Bruce Momjian (bruce@momjian.us)
|}

== Departure from Stuttgart Airport (STR) ==
{|
!!|Day||Time||Flight||Name/contact info
|-
|Thursday (Dec 9th)||15:15||AB6612||Andreas Zickel||zickel@hesgdv.de
|-
|Thursday (Dec 9th)||15:15||AB6612||Christopher Dove||dove@hesgdv.de
|-
|Thursday (Dec 9th)||15:30||BA0919||Thom Brown||thom@linux.com
|-
|Thursday (Dec 9th)||07:00||AF5581||Jean-Christophe Arnu ||jca@postgresql.fr
|-
|Friday (Dec 10th)||11:50||SK658||Magnus Hagander||magnus@hagander.net
|}

== Departure from Stuttgart Main Station ==
{|
!!|Day||Time||Train||Name/contact info
|-
|Wednesday (Dec 8th)||16:10||EC 144||Hartmut Holzgraefe & Susanne Ebrecht: <hartmut@php.net>
|-
|Thursday (Dec 9th)||05:51||ICE 616 || Giuseppe Maxia (datacharmer AT gmail dot com)
|}

== Departure from Frankfurt Airport (FRA) ==
{|
!!|Day||Time||Flight||Name/contact info
|-
|Thursday (Dec 9th)||10:50, Frankfurt-Terminal 2 (FRA)||EI0651||Peter Geoghegan (peter.geoghegan86@gmail.com, +353 863271976)
|-
|Thursday (Dec 9th)||09:40, Frankfurt-Terminal 2 (FRA)||AZ413||Giuseppe Maxia (datacharmer at gmail dot com)
|}

== Other ==
* I'm heading to Erfurt on Thursday (Dec 9th). Anyone going to that direction that could give me a ride? - Heikki Linnakangas (heikki@enterprisedb.com, +358405226830)

Refactor Type System

2010-11-12T22:11:49Z

Dfetter: /* Refactor the Type System */

= Refactor the Type System =

ISSUES:

Creaky typmod system

One 32-bit integer does not contain enough structure to describe
conveniently what a type should be. Pushing information into
userland, as PostGIS is forced to do, exposes these types to the
vicissitudes of user environment, search_path, etc.

Typmod is not preserved over all operations, leading to surprising
behavior.

Need to store a separate entry for a type's array and other possible multiplicities

Refactor Type System

2010-11-12T16:32:19Z

Dfetter: /* Refactor the Type System */

= Refactor the Type System =

ISSUES:

- Creaky typmod system

- Need to store a separate entry for a type's array and other possible multiplicities

Refactor Type System

2010-11-12T16:28:45Z

Dfetter: New page: = Refactor the Type System = TODO - Creaky typmod system - Need to store a separate entry for a type's array and other possible multiplicities

= Refactor the Type System =

TODO

- Creaky typmod system

- Need to store a separate entry for a type's array and other possible multiplicities

FAQ

2010-11-09T22:40:50Z

Dfetter: /* How do I find out about known bugs or missing features? */

{{Languages}}
[[:Category:FAQ|Additional FAQ Entries on this Wiki]]

== Translations of this Document ==

* [[Häufig gestellte Fragen|German]]
* [[Perguntas Frequentes|Portuguese]]
* [[Preguntas Frecuentes|Spanish]]

== Platform-specific questions ==

Windows users should also read the [[Running & Installing PostgreSQL On Native Windows|platform FAQ for Windows]]. There are [[Frequently Asked Questions#Platform FAQs|FAQs for other platforms]] too.

== General Questions ==

=== What is PostgreSQL? How is it pronounced? What is Postgres? ===

PostgreSQL is pronounced Post-Gres-Q-L. (For those curious about how
to say "PostgreSQL", an [http://www.postgresql.org/files/postgresql.mp3 audio file] is available.)

PostgreSQL is an object-relational database system that has the
features of traditional proprietary database systems with enhancements
to be found in next-generation DBMS systems. PostgreSQL is free and
the complete source code is available.

PostgreSQL development is performed by a team of mostly volunteer
developers spread throughout the world and communicating via the
Internet. It is a community project and is not controlled by any
company. To get involved, see the [[Developer_FAQ | Developer FAQ]].

Postgres is a widely-used nickname for PostgreSQL. It was the original
name of the project at Berkeley and is strongly preferred over other
nicknames. If you find 'PostgreSQL' hard to pronounce, call it
'Postgres' instead.

=== Who controls PostgreSQL? ===

If you are looking for a PostgreSQL gatekeeper, central committee, or
controlling company, give up --- there isn't one. We do have a core
committee and CVS committers, but these groups are more for
administrative purposes than control. The project is directed by the
community of developers and users, which anyone can join. All you need
to do is subscribe to the mailing lists and participate in the
discussions. (See the [[Developer FAQ|Developer's FAQ]] for information on how to get
involved in PostgreSQL development.)

=== Who is the PostgreSQL Global Development Group? ===

The "PGDG" is an international, unincorporated association of
individuals and companies who have contributed to the PostgreSQL
project. The PostgreSQL Core Team generally act as spokespeople
for the PGDG.

=== Who is the PostgreSQL Core Team? ===

A committee of five to seven (currently six) senior contributors to
PostgreSQL who do the following for the project: (a) set release dates,
(b) handle confidential matters for the project, (c) act as spokespeople
for the PGDG when required, and (d) arbitrate community decisions which
are not settled by consensus. The current Core Team is listed on top of
[http://www.postgresql.org/community/contributors/ the contributors page]

=== What about the various PostgreSQL foundations? ===

While the PostgreSQL project utilizes non-profit corporations in the
USA, Europe, Brazil and Japan for fundraising and project coordination,
these entities do not own the PostgreSQL code.

=== What is the license of PostgreSQL? ===

PostgreSQL is distributed under a license similar to BSD and MIT. Basically, it
allows users to do anything they want with the code, including
reselling binaries without the source code. The only restriction is
that you not hold us legally liable for problems with the software.
There is also the requirement that this copyright appear in all copies
of the software. Here is the license we use:

PostgreSQL Data Base Management System

Portions Copyright (c) 1996-2010, PostgreSQL Global Development Group
Portions Copyright (c) 1994-1996 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.

=== What platforms does PostgreSQL support? ===

In general, any modern Unix-compatible platform should be able to run
PostgreSQL. The platforms that have received recent explicit testing
can be seen in the [http://buildfarm.postgresql.org/ Build farm].
The documentation contains more details about supported platforms at http://www.postgresql.org/docs/current/static/supported-platforms.html.

PostgreSQL also runs natively on Microsoft Windows NT-based operating
systems like Win2000 SP4, WinXP, and Win2003. A prepackaged installer
is available at http://www.postgresql.org/download/windows.
MSDOS-based versions of Windows (Win95, Win98, WinMe) can run
PostgreSQL using Cygwin.

=== Where can I get PostgreSQL? ===

There are binary distributions for various operating systems and platforms; see [http://www.postgresql.org/download our download area].

The source code can be obtained [http://www.postgresql.org/ftp/ via web browser] or [ftp://ftp.postgresql.org/pub/ through ftp].

=== What is the most recent release? ===

The latest release of PostgreSQL is shown on the front page of [http://www.postgresql.org/ our website].

We typically have a major release every year, with minor releases every few months.
Minor releases are usually made at the same time for all supported major-release branches.
For more about major versus minor releases, see
http://www.postgresql.org/support/versioning.

=== Where can I get support? ===

The PostgreSQL community provides assistance to many of its users via
email. The main web site to subscribe to the email lists is
http://www.postgresql.org/community/lists/. The general or bugs lists
are a good place to start. For best results, consider reading the
[[guide to reporting problems]] before you post to make sure you
include enough information for people to help you.

The major IRC channel is #postgresql on Freenode (irc.freenode.net).
A Spanish one also
exists on the same network, (#postgresql-es), a French one,
(#postgresqlfr), and a Brazilian one, (#postgresql-br). There is also
a PostgreSQL channel on EFNet.

A list of support companies is available at
http://www.postgresql.org/support/professional_support.

=== How do I submit a bug report? ===

Visit the PostgreSQL bug form at
http://www.postgresql.org/support/submitbug to submit your bug
report to the pgsql-bugs mailing list. Also check out our ftp
site ftp://ftp.postgresql.org/pub/ to see if there is a more recent
PostgreSQL version.

For a prompt and helpful response, it is important for you to read the
[[guide to reporting problems]] to make sure that you include the
information required to fully understand and act on your report.

Bugs submitted using the bug form or posted to any PostgreSQL mailing
list typically generates one of the following replies:
* It is not a bug, and why
* It is a known bug and is already on the TODO list
* The bug has been fixed in the current release
* The bug has been fixed but is not packaged yet in an official release
* A request is made for more detailed information:
** Operating system
** PostgreSQL version
** Reproducible test case
** Debugging information
** [[Generating_a_stack_trace_of_a_PostgreSQL_backend|Debugger backtrace output]]
* The bug is new. The following might happen:
** A patch is created and will be included in the next major or minor release
** The bug cannot be fixed immediately and is added to the TODO list

=== How do I find out about known bugs or missing features? ===

PostgreSQL supports an extended subset of SQL:2008. See our [[Todo|TODO list]]
for known bugs, missing features, and future plans.

A feature request usually results in one of the following replies:
* The feature is already on the TODO list
* The feature is not desired because:
** It duplicates existing functionality that already follows the SQL standard
** The feature would increase code complexity but add little benefit
** The feature would be insecure or unreliable
* The new feature is added to the TODO list

PostgreSQL does not use a bug tracking system because we find it more
efficient to respond directly to email and keep the TODO list
up-to-date. In practice, bugs don't last very long in the software,
and bugs that affect a large number of users are fixed rapidly. The
only place to find all changes, improvements, and fixes in a
PostgreSQL release is to read the CVS log messages. Even the release
notes do not list every change made to the software.

=== A bug I'm encountering is fixed in a newer minor release of PostgreSQL, but I don't want to upgrade. Can I get a patch for just this issue? ===

No. Nobody will make a custom patch for you so you can (say) extract a fix from 8.4.3 and apply it to 8.4.1 .
That's because there should never be any need to do that.

PostgreSQL has a strict policy that only bug fixes are back-patched into point releases, as per the [http://www.postgresql.org/support/versioning version policy]. It is safe to upgrade from 8.4.1 to 8.4.3,
for example. Binary compatibility will be maintained, no dump and reload is required, nothing will break, but bugs that might
cause problems have been fixed. Even if you are not yet encountering a particular bug, you might later, and it is wise to upgrade promptly.
You just have to install the update and re-start the database server, nothing more.

Upgrading from 8.3 to 8.4, or 8.4 to 9.0, is a major upgrade that does not come with the same guarantees. However, if a bug
is discovered in 9.0 then it will generally be fixed in all maintained older versions like 8.4 and 8.3 if it is safe and
practical to do so.

This means that if you're running 8.1.0, upgrading to 8.1.21 is strongly recommended and very safe. On the other hand,
upgrading to the next major release, 8.2.x, may require changes to your app, and will certainly require a dump and reload.

If you want to be careful about all upgrades, you should read the [http://www.postgresql.org/docs/current/static/release.html release notes]
for each point release between your current one and the latest minor version of the same major release carefully. If you're
exceptionally paranoid about upgrades, you can fetch the source code to each set of point release changes from [http://git.postgresql.org/ PostgreSQL's git repository] and examine it.

It is strongly recommended that you always upgrade to the latest minor release. Avoid trying to extract and apply individual fixes
from point releases; by doing so you're bypassing all the QA done by the PostgreSQL team when they prepare a release, and are creating your
own custom version that nobody else has ever used. It's a lot safer to just update to the latest tested, safe release. Patching your own custom, non-standard build will also take more time/effort, and will require the same amount of downtime as a normal upgrade.

=== I have a program that says it wants PostgreSQL x.y.1. Can I use PostgreSQL x.y.2 instead? ===

Any program that works with a particular version, like 8.4.1, should work with any other minor version in the same major version. That means that if a program says it wants (eg) 8.4.1, you can and should install the latest in the 8.4 series instead.

See the previous question for more details.

=== What documentation is available? ===

PostgreSQL includes extensive documentation, including a large manual,
manual pages, and some test examples. See the /doc directory. You can
also browse the manuals online at http://www.postgresql.org/docs.

There are a number of PostgreSQL
books available for purchase; two of them are also available online. A list of books can be found at
http://www.postgresql.org/docs/books/. One of the most popular ones is the one by Korry & Susan
Douglas.

There is also a collection of
PostgreSQL technical articles on the
[[Community_Generated_Articles%2C_Guides%2C_and_Documentation | wiki]].

The command line client program psql has some \d commands to show
information about types, operators, functions, aggregates, etc. - use
\? to display the available commands.

=== How can I learn SQL? ===

First, consider the PostgreSQL-specific books mentioned above. Many of
our users also like The Practical SQL Handbook, Bowman, Judith S., et
al., Addison-Wesley. Others like The Complete Reference SQL, Groff et
al., McGraw-Hill.

Many people consider the PostgreSQL documentation to be an excellent guide
for learning SQL its self, as well as for PostgreSQL's implementation of it.
For best results use PostgreSQL alongside another full-featured SQL database as
you learn, so you get used to SQL without becoming reliant on PostgreSQL-specific
features. The PostgreSQL documentation generally mentions when features are PostgreSQL
extensions of the standard.

There are also many nice tutorials available online:
* 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
* http://sqlzoo.net

=== How do I submit a patch or join the development team? ===

See the [[Developer FAQ|Developer's FAQ]].

=== How does PostgreSQL compare to other DBMSs? ===

There are several ways of measuring software: features, performance,
reliability, support, and price.

==== Features ====

PostgreSQL has most features present in large proprietary DBMSs,
like transactions, subselects, triggers, views, foreign key
referential integrity, and sophisticated locking. We have some
features they do not have, like user-defined types,
inheritance, rules, and multi-version concurrency control to
reduce lock contention.

==== Performance ====

PostgreSQL's performance is comparable to other proprietary and
open source databases. It is faster for some things, slower for
others. Our performance is usually +/-10% compared to other databases.

==== Reliability ====

We realize that a DBMS must be reliable, or it is worthless. We
strive to release well-tested, stable code that has a minimum
of bugs. Each release has at least one month of beta testing,
and our release history shows that we can provide stable, solid
releases that are ready for production use. We believe we
compare favorably to other database software in this area.

==== Support ====

Our mailing lists provide contact with a large group of
developers and users to help resolve any problems encountered.
While we cannot guarantee a fix, proprietary DBMSs do not always
supply a fix either. Direct access to developers, the user
community, manuals, and the source code often make PostgreSQL
support superior to other DBMSs. There is commercial
per-incident support available for those who need it. (See [[#Where_can_I_get_support.3F | section 1.7]]).

==== Price ====

We are free for all use, both proprietary and open source.
You can add our code to your product with no limitations,
except those outlined in our BSD-style license stated above.

=== Can PostgreSQL be embedded? ===

PostgreSQL is designed as a client/server architecture, which requires
separate processes for each client and server, and various helper
processes. Many embedded architectures can support such requirements.
However, if your embedded architecture requires the database server to
run inside the application process, you cannot use Postgres and should
select a lighter-weight database solution.

Popular embeddable options include [http://sqlite.org SQLite] and [http://firebirdsql.org Firebird SQL].

=== How do I unsubscribe from the PostgreSQL email lists? How do I avoid receiving duplicate emails? ===

The PostgreSQL Majordomo page allows subscribing or unsubscribing from
any of the PostgreSQL email lists. (You might need to have your
Majordomo password emailed to you to log in.)

All PostgreSQL email lists are configured so a group reply goes to the
email list and the original email author. This is done so users
receive the quickest possible email replies. If you would prefer not
to receive duplicate email from the list in cases where you already
receive an email directly, check eliminatecc from the Majordomo Change
Settings page. You can also prevent yourself from receiving copies of
emails you post to the lists by unchecking selfcopy.

== User Client Questions ==

=== What interfaces are available for PostgreSQL? ===

The PostgreSQL install includes only the C and embedded C interfaces.
All other interfaces are independent projects that are downloaded
separately; being separate allows them to have their own release
schedule and development teams.

Some programming languages like PHP include an interface to
PostgreSQL. Interfaces for languages like Perl, TCL, Python, and many
others are available at http://pgfoundry.org.

=== What tools are available for using PostgreSQL with Web pages? ===

A nice introduction to Database-backed Web pages can be seen at:
http://www.webreview.com

For Web integration, PHP (http://www.php.net) is an excellent
interface.

For complex cases, many use the Perl and DBD::Pg with CGI.pm or
mod_perl.

=== Does PostgreSQL have a graphical user interface? ===

There are a large number of GUI Tools that are available for
PostgreSQL from both proprietary and open source developers. A detailed
list can be found in the [[Community Guide to PostgreSQL GUI Tools]].

== Administrative Questions ==

=== How do I install PostgreSQL somewhere other than /usr/local/pgsql? ===

Specify the --prefix option when running configure.

=== I'm installing PostgreSQL and don't know the password for the postgres user ===

Dave Page wrote a [http://pgsnake.blogspot.com/2010/07/postgresql-passwords-and-installers.html blog post] explaining what the different passwords are used for, and how to overcome common problems such as resetting them.

=== How do I control connections from other hosts? ===

By default, PostgreSQL only allows connections from the local machine
using Unix domain sockets or TCP/IP connections. Other machines will
not be able to connect unless you modify listen_addresses in the
postgresql.conf file, enable host-based authentication by modifying
the $PGDATA/pg_hba.conf file, and restart the database server.

=== How do I tune the database engine for better performance? ===

There are three major areas for potential performance improvement:

==== Query Changes ====
This involves modifying queries to obtain better performance:

* Creation of indexes, including expression and partial indexes
* Use of COPY instead of multiple INSERTs
* Grouping of multiple statements into a single transaction to reduce commit overhead
* Use of CLUSTER when retrieving many rows from an index
* Use of LIMIT for returning a subset of a query's output
* Use of Prepared queries
* Use of ANALYZE to maintain accurate optimizer statistics
* Regular use of VACUUM or pg_autovacuum
* Dropping of indexes during large data changes

==== Server Configuration ====
A number of postgresql.conf settings affect performance. For
more details, see Administration Guide/Server Run-time
Environment/Run-time Configuration.

==== Hardware Selection ====
The effect of hardware on performance is detailed in
http://www.powerpostgresql.com/PerfList/ and
http://momjian.us/main/writings/pgsql/hw_performance/index.html.

=== What debugging features are available? ===

There are many log_* server configuration variables at http://www.postgresql.org/docs/current/interactive/runtime-config-logging.html that enable printing of query and process statistics which can be very useful for debugging and performance measurements.

=== Why do I get "Sorry, too many clients" when trying to connect? ===

You have reached the default limit of 100 database sessions. You need
to increase the server's limit on how many concurrent backend
processes it can start by changing the max_connections value in
postgresql.conf and restarting the server.

=== What is the upgrade process for PostgreSQL? ===

See http://www.postgresql.org/support/versioning for a general
discussion about upgrading, and
http://www.postgresql.org/docs/current/static/install-upgrading.html
for specific instructions.

=== Will PostgreSQL handle recent daylight saving time changes in various countries? ===

PostgreSQL releases 8.0 and up depend on the widely-used tzdata database
(also called the zoneinfo database or the [http://www.twinsun.com/tz/tz-link.htm Olson timezone database]) for
daylight savings information. To deal with a DST law change that affects you,
install a new tzdata file set and restart the server.

All PostgreSQL update releases include the latest available tzdata files,
so keeping up-to-date on minor releases for your major version is usually
sufficient for this.

On platforms that receive regular software updates including new tzdata files,
it may be more convenient to rely on the system's copy of the tzdata files.
This is possible as a compile-time option. Most Linux distributions choose
this approach for their pre-built versions of PostgreSQL.

PostgreSQL releases before 8.0 always rely on the operating system's timezone
information.

=== What computer hardware should I use? ===

Because PC hardware is mostly compatible, people tend to believe that
all PC hardware is of equal quality. It is not. ECC RAM, SCSI, and
quality motherboards are more reliable and have better performance
than less expensive hardware. PostgreSQL will run on almost any
hardware, but if reliability and performance are important it is wise
to research your hardware options thoroughly.

Database servers, unlike many other applications, are usually I/O and memory constrained, so it is wise to focus on the I/O subsystem first, then memory capacity, and lastly consider CPU issues. For example, a disk controller with a
battery-backed cache is often the cheapest and easiest way to improve database performance. Our email lists can be used to discuss hardware options and tradeoffs.

=== How does PostgreSQL use CPU resources? ===

The PostgreSQL server is process-based (not threaded), and uses one operating system process per database session. A single database session (connection) cannot utilize more than one CPU. Of course, multiple sessions are automatically spread across all available CPUs by your operating system. Client applications can easily use threads and create multiple database connections from each thread.

A single complex and CPU-intensive query is unable to use more than one CPU to do the processing for the query. The OS may still be able to use others for disk I/O etc, but you won't see much benefit from more than one spare core.

=== Why does PostgreSQL have so many processes, even when idle? ===

As noted in [[FAQ#How does PostgreSQL use CPU resources?|the answer above]], PostgreSQL is process based, so it starts one <code>postgres</code> (or <code>postgres.exe</code> on Windows) instance per connection. The postmaster (which accepts connections and starts new postgres instances for them) is always running. In addition, PostgreSQL generally has one or more "helper" processes like the stats collector, background writer, autovacuum daemon, walsender, etc, all of which show up as "postgres" instances in most system monitoring tools.

Despite the number of processes, they actually use very little in the way of real resources. See [[FAQ#Why does PostgreSQL show up as using so much memory in my system monitoring tool?|the next answer]].

=== Why does PostgreSQL use so much memory? ===

Despite appearances, this is absolutely normal, and there's actually nowhere near as much memory being used as tools like <code>top</code> or the Windows process monitor say PostgreSQL is using.

Tools like <code>top</code> and the Windows process monitor may show many <code>postgres</code> instances (see above), each of which appears to use a huge amount of memory. Often, when added up, the amount the postgres instances use is many times the amount of memory actually installed in the computer!

This is a consequence of how these tools report memory use. They generally don't understand shared memory very well, and show it as if it was memory used individually and exclusively by each postgres instance. PostgreSQL uses a big chunk of shared memory to communicate between its backends and cache data. Because these tools count that shared memory block once per <code>postgres</code> instance instead of counting it once for all <code>postgres</code> instances, they massively over-estimate how much memory PostgreSQL is using.

== Operational Questions ==

=== How do I SELECT only the first few rows of a query? A random row? ===

To retrieve only a few rows, if you know at the number of rows needed
at the time of the SELECT use LIMIT . If an index matches the ORDER BY
it is possible the entire query does not have to be executed. If you
don't know the number of rows at SELECT time, use a cursor and FETCH.

To SELECT a random row, use:
SELECT col
FROM tab
ORDER BY random()
LIMIT 1;

See also this [http://blog.rhodiumtoad.org.uk/2009/03/08/selecting-random-rows-from-a-table/ blog entry by Andrew Gierth]
that has more information on this topic.

=== How do I find out what tables, indexes, databases, and users are defined? How do I see the queries used by psql to display them? ===

Use the \dt command to see tables in psql. For a complete list of
commands inside psql you can use \?. Alternatively you can read the
source code for psql in file pgsql/src/bin/psql/describe.c, it
contains SQL commands that generate the output for psql's backslash
commands. You can also start psql with the -E option so it will print
out the queries it uses to execute the commands you give. PostgreSQL
also provides an SQL compliant INFORMATION SCHEMA interface you can
query to get information about the database.

There are also system tables beginning with pg_ that describe these
too.

Use psql -l will list all databases.

Also try the file pgsql/src/tutorial/syscat.source. It illustrates
many of the SELECTs needed to get information from the database system
tables.

=== How do you change a column's data type? ===

Changing the data type of a column can be done easily in 8.0 and later
with ALTER TABLE ALTER COLUMN TYPE.

In earlier releases, do this:
BEGIN;
ALTER TABLE tab ADD COLUMN new_col new_data_type;
UPDATE tab SET new_col = CAST(old_col AS new_data_type);
ALTER TABLE tab DROP COLUMN old_col;
COMMIT;

You might then want to do VACUUM FULL tab to reclaim the disk space
used by the expired rows.

=== What is the maximum size for a row, a table, and a database? ===

These are the limits:

Maximum size for a database? unlimited (32 TB databases exist)
Maximum size for a table? 32 TB
Maximum size for a row? 400 GB
Maximum size for a field? 1 GB
Maximum number of rows in a table? unlimited
Maximum number of columns in a table? 250-1600 depending on column types
Maximum number of indexes on a table? unlimited

Of course, these are not actually unlimited, but limited to available
disk space and memory/swap space. Performance may suffer when these
values get unusually large.

The maximum table size of 32 TB does not require large file support
from the operating system. Large tables are stored as multiple 1 GB
files so file system size limits are not important.

The maximum table size, row size, and maximum number of columns can be
quadrupled by increasing the default block size to 32k. The maximum
table size can also be increased using table partitioning.

One limitation is that indexes can not be created on columns longer
than about 2,000 characters. Fortunately, such indexes are rarely
needed. Uniqueness is best guaranteed by a function index of an MD5
hash of the long column, and full text indexing allows for searching
of words within the column.

=== How much database disk space is required to store data from a typical text file? ===

A PostgreSQL database may require up to five times the disk space to
store data from a text file.

As an example, consider a file of 100,000 lines with an integer and
text description on each line. Suppose the text string averages
twenty bytes in length. The flat file would be 2.8 MB. The size of the
PostgreSQL database file containing this data can be estimated as 5.2
MB:
24 bytes: each row header (approximate)
24 bytes: one int field and one text field
+ 4 bytes: pointer on page to tuple
----------------------------------------
52 bytes per row

The data page size in PostgreSQL is 8192 bytes (8 KB), so:

8192 bytes per page
------------------- = 158 rows per database page (rounded down)
52 bytes per row

100000 data rows
------------------ = 633 database pages (rounded up)
158 rows per page

633 database pages * 8192 bytes per page = 5,185,536 bytes (5.2 MB)

Indexes do not require as much overhead, but do contain the data that
is being indexed, so they can be large also.

NULLs are stored as bitmaps, so they use very little space.

Note that long values may be compressed transparently.

See also this presentation on the topic: [[Image:How_Long_Is_a_String.pdf]].

=== Why are my queries slow? Why don't they use my indexes? ===

Indexes are not used by every query. Indexes are used only if the
table is larger than a minimum size, and the query selects only a
small percentage of the rows in the table. This is because the random
disk access caused by an index scan can be slower than a straight read
through the table, or sequential scan.

To determine if an index should be used, PostgreSQL must have
statistics about the table. These statistics are collected using
VACUUM ANALYZE, or simply ANALYZE. Using statistics, the optimizer
knows how many rows are in the table, and can better determine if
indexes should be used. Statistics are also valuable in determining
optimal join order and join methods. Statistics collection should be
performed periodically as the contents of the table change.

Indexes are normally not used for ORDER BY or to perform joins. A
sequential scan followed by an explicit sort is usually faster than an
index scan of a large table. However, LIMIT combined with ORDER BY
often will use an index because only a small portion of the table is
returned.

If you believe the optimizer is incorrect in choosing a sequential
scan, use SET enable_seqscan TO 'off' and run query again to see if an
index scan is indeed faster.

When using wild-card operators such as LIKE or ~, indexes can only be
used in certain circumstances:

* The beginning of the search string must be anchored to the start of the string, i.e.
** LIKE patterns must not start with % or _.
** ~ (regular expression) patterns must start with ^.

* The search string can not start with a character class, e.g. [a-e].

* Case-insensitive searches such as ILIKE and ~* do not utilize indexes. Instead, use expression indexes, which are described in [[#How_do_I_perform_regular_expression_searches_and_case-insensitive_regular_expression_searches.3F_How_do_I_use_an_index_for_case-insensitive_searches.3F | section 4.8]].

* C locale must be used during initdb because sorting in a non-C locale often doesn't match the behavior of LIKE. You can create a special text_pattern_ops index that will work in such cases, but note it is only helpful for LIKE indexing.

It is also possible to use full text indexing for word searches.

The [[SlowQueryQuestions]] article contains some more tips and guidance.

=== How do I see how the query optimizer is evaluating my query? ===

This is done with the EXPLAIN command; see [[Using EXPLAIN]].

=== How do I change the sort ordering of textual data? ===

PostgreSQL sorts textual data according to the ordering that is defined by the current locale, which is selected during initdb.
(In 8.4 and up it will be possible to select a different locale when creating a new database.)
If you don't like the ordering then you need to use a different locale.
In particular, most locales other than "C" sort according to dictionary order, which largely ignores punctuation and spacing.
If that's not what you want then you need "C" locale.

=== How do I perform regular expression searches and case-insensitive regular expression searches? How do I use an index for case-insensitive searches? ===

The ~ operator does regular expression matching, and ~* does
case-insensitive regular expression matching. The case-insensitive
variant of LIKE is called ILIKE.

Case-insensitive equality comparisons are normally expressed as:
SELECT *
FROM tab
WHERE lower(col) = 'abc';

This will not use a standard index on "col". However, if you create an
expression index on "lower(col)", it will be used:
CREATE INDEX tabindex ON tab (lower(col));

If the above index is created as UNIQUE, then the column can store
upper and lowercase characters, but it cannot contain identical values that
differ only in case. To force a particular case to be stored in the
column, use a CHECK constraint or a trigger.

In PostgreSQL 8.4 and later, you can also use the contributed [http://www.postgresql.org/docs/8.4/static/citext.html CITEXT data type], which internally implements the "lower()" calls, so that you can effectively treat it as a fully case-insensitive data type. CITEXT is also [https://svn.kineticode.com/citext/trunk/ available for 8.3], and an earlier version that treats only ASCII characters case-insensitively on 8.2 and earlier is available on [http://pgfoundry.org/projects/citext/ pgFoundry].

=== In a query, how do I detect if a field is NULL? How do I concatenate possible NULLs? How can I sort on whether a field is NULL or not? ===

You can test the value with IS NULL or IS NOT NULL, like this:
SELECT *
FROM tab
WHERE col IS NULL;

Concatenating a NULL with something else produces another NULL.
If that's not what you want, you can replace the NULL(s) using
COALESCE(), like this:
<nowiki>SELECT COALESCE(col1, '') || COALESCE(col2, '')</nowiki>
FROM tab;

To sort by the NULL status, use an IS NULL or IS NOT NULL test
in your ORDER BY clause. Things that are true will sort higher than
things that are false, so the following will put NULL entries at the
front of the output:
SELECT *
FROM tab
ORDER BY (col IS NOT NULL), col;

In PostgreSQL 8.3 and up, you can also control sort ordering of NULLs
using the recently-standardized NULLS FIRST/NULLS LAST modifiers,
like this:
SELECT *
FROM tab
ORDER BY col NULLS FIRST;

=== What is the difference between the various character types? ===

{| border="1"
!Type
!Internal Name
!Notes
|-
|VARCHAR(n)
|varchar
|size specifies maximum length, no padding
|-
|CHAR(n)
|bpchar
|blank-padded to the specified fixed length
|-
|TEXT
|text
|no specific upper limit on length
|-
|BYTEA
|bytea
|variable-length byte array (null-byte safe)
|-
|"char" (with the quotes)
|char
|one byte
|}

You will see the internal name when examining system catalogs and in
some error messages.

The first four types above are "varlena" types (i.e., the field length
is explicitly stored on disk, followed by the data). Thus the actual
space used is slightly greater than the expected size. However, long
values are also subject to compression, so the space on disk might
also be less than expected.

VARCHAR(n) is best when storing variable-length strings if a specific
upper limit on the string length is required by the application.
TEXT is for strings of "unlimited" length (though all fields in PostgreSQL
are subject to a maximum value length of one gigabyte).

CHAR(n) is for storing strings that are all the same length. CHAR(n)
pads with blanks to the specified length, while VARCHAR(n) only stores
the characters supplied. BYTEA is for storing binary data,
particularly values that include zero bytes. All these types have similar
performance characteristics, except that the blank-padding involved
in CHAR(n) requires additional storage and some extra runtime.

The "char" type (the quotes are required to distinguish it from CHAR(n))
is a specialized datatype that can store exactly one byte. It is found in
the system catalogs but its use in user tables is generally discouraged.

=== How do I create a serial/auto-incrementing field? ===

PostgreSQL supports a SERIAL data type. Actually, this isn't quite
a real type. It's a shorthand for creating an integer column that
is fed from a sequence.

For example, this:
CREATE TABLE person (
id SERIAL,
name TEXT
);
is automatically translated into this:
CREATE SEQUENCE person_id_seq;
CREATE TABLE person (
id INTEGER NOT NULL DEFAULT nextval('person_id_seq'),
name TEXT
);

The automatically created sequence is named ''table''_''serialcolumn''_seq,
where ''table'' and ''serialcolumn'' are the names of the table and SERIAL
column, respectively. See the CREATE SEQUENCE manual page for more
information about sequences.

There is also BIGSERIAL, which is like SERIAL except that the resulting
column is of type BIGINT instead of INTEGER. Use this type if you think
that you might need more than 2 billion serial values over the lifespan
of the table.

=== How do I get the value of a SERIAL insert? ===

The simplest way is to retrieve the assigned SERIAL value with
RETURNING. Using the example table in the previous question, it would look like this:
INSERT INTO person (name) VALUES ('Blaise Pascal') RETURNING id;

You can also call nextval() and use that value in the INSERT, or call
currval() after the INSERT.

=== Doesn't currval() lead to a race condition with other users? ===

No. currval() returns the latest sequence value assigned by your session,
independently of what is happening in other sessions.

=== Why are there gaps in the numbering of my sequence/SERIAL column? Why aren't my sequence numbers reused on transaction abort? ===

To improve concurrency, sequence values are given out to running
transactions on-demand; the sequence object is not kept locked but is
immediately available for another transaction to get another sequence
value. This causes gaps in numbering from aborted transactions.

=== What is an OID? ===

If a table is created WITH OIDS, each row includes an OID column that is automatically filled in during INSERT.
OIDs are sequentially assigned 4-byte integers. Initially they are unique
across the entire installation. However, the OID counter wraps around at 4 billion,
and after that OIDs may be duplicated.

It is possible to prevent duplication of OIDs within a single table by
creating a unique index on the OID column (but note that the WITH OIDS
clause doesn't by itself create such an index).
The system checks the index to see if a newly
generated OID is already present, and if so generates a new OID and
repeats. This works well so long as no OID-containing table has
more than a small fraction of 4 billion rows.

PostgreSQL uses OIDs for object identifiers in the system catalogs,
where the size limit is unlikely to be a problem.

To uniquely number rows in user tables, it is best to use SERIAL
rather than an OID column, or BIGSERIAL if the table is expected to
have more than 2 billion entries over its lifespan.

=== What is a CTID? ===

CTIDs identify specific physical rows by their block and
offset positions within a table.
They are used by index entries to point to physical rows.
A logical row's CTID changes when it is updated, so the CTID
cannot be used as a long-term row identifier. But it is sometimes
useful to identify a row within a transaction when no competing
update is expected.

=== Why do I get the error "ERROR: Memory exhausted in AllocSetAlloc()"? ===

You probably have run out of virtual memory on your system, or your
kernel has a low limit for certain resources. Try this before starting
the server:
ulimit -d 262144
limit datasize 256m

Depending on your shell, only one of these may succeed, but it will
set your process data segment limit much higher and perhaps allow the
query to complete. This command applies to the current process, and
all subprocesses created after the command is run. If you are having a
problem with the SQL client because the backend is returning too much
data, try it before starting the client.

=== How do I tell what PostgreSQL version I am running? ===

Run this query: SELECT version();

=== Is there a way to leave an audit trail of database operations? ===

There's nothing built-in, but it's not too difficult to build such
facilities yourself.

Simple example right in the official docs:
http://www.postgresql.org/docs/8.3/static/plpgsql-trigger.html#PLPGSQL-TRIGGER-AUDIT-EXAMPLE

Project targeting this feature: http://pgfoundry.org/projects/tablelog/

Background information and other sample implementations:
http://it.toolbox.com/blogs/database-soup/simple-data-auditing-19014
http://www.go4expert.com/forums/showthread.php?t=7252
http://www.alberton.info/postgresql_table_audit.html

=== How do I create a column that will default to the current time? ===

Use CURRENT_TIMESTAMP:
CREATE TABLE test (x int, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

=== How do I perform an outer join? ===

PostgreSQL supports outer joins using the SQL standard syntax. Here
are two examples:
SELECT *
FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col);

or
SELECT *
FROM t1 LEFT OUTER JOIN t2 USING (col);

These identical queries join t1.col to t2.col, and also return any
unjoined rows in t1 (those with no match in t2). A RIGHT join would
add unjoined rows of t2. A FULL join would return the matched rows
plus all unjoined rows from t1 and t2. The word OUTER is optional and
is assumed in LEFT, RIGHT, and FULL joins. Ordinary joins are called
INNER joins.

=== How do I perform queries using multiple databases? ===

There is no way to query a database other than the current one.
Because PostgreSQL loads database-specific system catalogs, it is
uncertain how a cross-database query should even behave.

contrib/dblink allows cross-database queries using function calls. Of
course, a client can also make simultaneous connections to different
databases and merge the results on the client side.

=== How do I return multiple rows or columns from a function? ===

It is easy using set-returning functions,
[[Return more than one row of data from PL/pgSQL functions]].

=== Why do I get "relation with OID ##### does not exist" errors when accessing temporary tables in PL/PgSQL functions? ===

In PostgreSQL versions < 8.3, PL/PgSQL caches function scripts, and an
unfortunate side effect is that if a PL/PgSQL function accesses a
temporary table, and that table is later dropped and recreated, and
the function called again, the function will fail because the cached
function contents still point to the old temporary table. The solution
is to use EXECUTE for temporary table access in PL/PgSQL. This will
cause the query to be reparsed every time.

This problem does not occur in PostgreSQL 8.3 and later.

=== What replication solutions are available? ===

Though "replication" is a single term, there are several technologies
for doing replication, with advantages and disadvantages for each.
Our documentation contains a good introduction to this topic at
http://www.postgresql.org/docs/8.3/static/high-availability.html and a
grid listing replication software and features is at
[[Replication, Clustering, and Connection Pooling]]

Master/slave replication allows a single master to receive read/write
queries, while slaves can only accept read/SELECT queries. The most
popular freely available master-slave PostgreSQL replication solution
is Slony-I.

Multi-master replication allows read/write queries to be sent to
multiple replicated computers. This capability also has a severe
impact on performance due to the need to synchronize changes between
servers. PGCluster is the most popular such solution freely available
for PostgreSQL.

There are also proprietary and hardware-based replication solutions
available supporting a variety of replication models.

=== Is possible to create a shared-storage postgresql server cluster? ===

PostgreSQL does not support clustering using [[Shared_Storage|shared storage]] on a SAN, SCSI backplane,
iSCSI volume, or other shared media. Such "RAC-style" clustering isn't supported.
Only replication-based clustering is currently supported.

See [[Replication, Clustering, and Connection Pooling]] information for details.

[[Shared_Storage|Shared-storage]] 'failover' is possible, but it is not safe to have more than one
postmaster running and accessing the data store at the same time. Heartbeat and
[http://en.wikipedia.org/wiki/STONITH STONITH] or some other hard-disconnect option are recommended.

=== Why are my table and column names not recognized in my query? Why is capitalization not preserved? ===

The most common cause of unrecognized names is the use of
double-quotes around table or column names during table creation. When
double-quotes are used, table and column names (called identifiers)
are stored case-sensitive, meaning you must use double-quotes when
referencing the names in a query. Some interfaces, like pgAdmin,
automatically double-quote identifiers during table creation. So, for
identifiers to be recognized, you must either:

* Avoid double-quoting identifiers when creating tables
* Use only lowercase characters in identifiers
* Double-quote identifiers when referencing them in queries

=== I lost the database password. What can I do to recover it? ===

You can't. However, you can reset it to something else. To do this, you

* edit pg_hba.conf to allow ''trust'' authorization temporarily
* Reload the config file (pg_ctl reload)
* Connect and issue ALTER ROLE / PASSWORD to set the new password
* edit pg_hba.conf again and restore the previous settings
* Reload the config file again

=== Does PostgreSQL have stored procedures? ===

PostgreSQL doesn't. However PostgreSQL have very powerful functions and user-defined functions capabilities that can do most things that other RDBMS stored routines (procedures and functions) can do and in many cases more.

These functions can be of different types and can be implemented in several programming languages.
(Refer to documentation for more details. [http://www.postgresql.org/docs/current/static/xfunc.html User-Defined Functions])

PostgreSQL functions can be invoked in many ways. If you want to invoke a function as you would call a stored procedure in other RDBMS (typically a function with side-effects but whose result you don't care for example because it returns void), one option would be to use [http://www.postgresql.org/docs/current/static/plpgsql.html PL/pgSQL Language] for your procedure and the [http://www.postgresql.org/docs/current/static/plpgsql-statements.html#PLPGSQL-STATEMENTS-SQL-NORESULT PERFORM] command. Example:
PERFORM theNameOfTheFunction(arg1, arg2);

Note that invoking instead:
SELECT theNameOfTheFunction(arg1, arg2);
would produce a result even if the function returns void (this result would be one row containing a void value).

[http://www.postgresql.org/docs/current/static/plpgsql-statements.html#PLPGSQL-STATEMENTS-SQL-NORESULT PERFORM] could thus be used to discard this unuseful result.

The main limitations on Pg's stored functions - as compared to true stored procedures - are:

* inability to return multiple result sets
* no support for autonomous transactions (<code>BEGIN</code>, <code>COMMIT</code> and <code>ROLLBACK</code> within a function)
* no support for the SQL-standard <code>CALL</code> syntax, though the ODBC and JDBC drivers will translate calls for you.

=== Why don't BEGIN, ROLLBACK and COMMIT work in stored procedures/functions? ===

PostgreSQL doesn't support autonomous transactions in its stored functions. Like all PostgreSQL queries, stored functions always run in a transaction and cannot operate outside a transaction.

If you need a stored procedure to manage transactions, you can look into the dblink interface or do the work from a client-side script instead. In some cases you can do what you need to using [http://www.postgresql.org/docs/current/static/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING exception blocks in PL/PgSQL], because each BEGIN/EXCEPTION/END block creates a subtransaction.

=== Why is "SELECT count(*) FROM bigtable;" slow? ===

It can't be answered directly from an index. PostgreSQL has to check the visibility for each record, so it
forces a sequential scan of the entire table. If you want, you can keep track of the number of rows yourself with triggers, but beware that this will slow down write access to the table.

You can get an estimation. The reltuples column in [http://www.postgresql.org/docs/current/static/catalog-pg-class.html pg_class] contains the information from the latest [http://www.postgresql.org/docs/current/static/sql-analyze.html ANALYZE] of the table. On a large table this is often accurate to within a few thousandths of a percent, which is accurate enough for many purposes.

An "exact" count is often not exact for very long, anyway; due to [http://www.postgresql.org/docs/current/static/mvcc-intro.html MVCC] concurrency, the count will be accurate as of the moment the SELECT count(*) query (or, for stricter [http://www.postgresql.org/docs/current/static/transaction-iso.html transaction isolation] levels, its transaction) ''started'', and may well be out-of-date by the time the query completes. In a transaction mix where the table is being modified, two count(*) executions which return at the same moment might have different values, if a modifying transaction committed between their start times.

For more information, see [[Slow Counting]].

=== Why is my query much slower when run as a prepared query? ===

When PostgreSQL has the full query with all parameters known by planning time, it can use statistics in the table to find out if the values used in the query are very common or very uncommon in a column. This lets it change the way it fetches the data to be more efficient, as it knows to expect lots or very few results from a certain part of the query. For example, it might choose an sequential scan instead of doing an index scan if you search for 'active=y' and it knows that 99% of the records in the table have 'active=y', because in this case a sequential scan will be much faster.

In a prepared query, PostgreSQL doesn't have the value of all parameters when it's creating the plan. It has to try to pick a "safe" plan that should work fairly well no matter what value you supply as the parameter when you execute the prepared query. Unfortunately, this plan might not be very appropriate if the value you supply is vastly more common, or vastly less common, than is average for some randomly selected values in the table.

If you suspect this issue is affecting you, start by using the [http://www.postgresql.org/docs/current/static/sql-explain.html EXPLAIN] command to compare the slow and fast queries. Look at the output of <code>EXPLAIN SELECT query...</code> and compare it to the result of <code>PREPARE query... ; EXPLAIN EXECUTE query...</code> to see if the plans are notably different. <code>EXPLAIN ANALYZE</code> may give you more information, such as row count estimates and counts.

Usually people having this problem are trying to use prepared queries as a security measure to prevent SQL injection, rather than as a performance tuning option for expensive-to-plan queries frequently executed with a variety of different parameters. Those people should consider using client-side prepared statements if their client interface (eg PgJDBC) supports it.

At present, PostgreSQL does not offer a way to request re-planning of a prepared statement using a particular set of parameter values; doing so somewhat defeats the purpose of server-side prepared statements. Running a statistics check to see if a particular parameter value is notably outside the norm and automatically re-planning in that case has been discussed, but not agreed upon or implemented as yet.

See [[Using_EXPLAIN]]. If you're going to ask for help on the mailing lists, please read the [[Guide to reporting problems]].

=== Why is my query much slower when run in a function than standalone? ===

See [[FAQ#Why is my query much slower when run as a prepared query?]]. Queries in PL/PgSQL functions are prepared and cached, so they execute in much the same way as if you'd <code>PREPARE</code>d then <code>EXECUTE</code>d the query yourself.

If you're having really severe issues with this that improving the table statistics or adjusting your query don't help with, you can work around it by forcing PL/PgSQL to re-prepare your query at every execution. To do this, use the <code>EXECUTE ... USING</code> statement in PL/PgSQL to supply your query as a textual string. Alternately, the [http://www.postgresql.org/docs/current/static/functions-string.html quote_literal or quote_nullable] functions may be used to escape parameters substituted into query text.

[[Category:FAQ]]

FAQ

2010-11-09T22:23:14Z

Dfetter: /* What is the license of PostgreSQL? */

{{Languages}}
[[:Category:FAQ|Additional FAQ Entries on this Wiki]]

== Translations of this Document ==

* [[Häufig gestellte Fragen|German]]
* [[Perguntas Frequentes|Portuguese]]
* [[Preguntas Frecuentes|Spanish]]

== Platform-specific questions ==

Windows users should also read the [[Running & Installing PostgreSQL On Native Windows|platform FAQ for Windows]]. There are [[Frequently Asked Questions#Platform FAQs|FAQs for other platforms]] too.

== General Questions ==

=== What is PostgreSQL? How is it pronounced? What is Postgres? ===

PostgreSQL is pronounced Post-Gres-Q-L. (For those curious about how
to say "PostgreSQL", an [http://www.postgresql.org/files/postgresql.mp3 audio file] is available.)

PostgreSQL is an object-relational database system that has the
features of traditional proprietary database systems with enhancements
to be found in next-generation DBMS systems. PostgreSQL is free and
the complete source code is available.

PostgreSQL development is performed by a team of mostly volunteer
developers spread throughout the world and communicating via the
Internet. It is a community project and is not controlled by any
company. To get involved, see the [[Developer_FAQ | Developer FAQ]].

Postgres is a widely-used nickname for PostgreSQL. It was the original
name of the project at Berkeley and is strongly preferred over other
nicknames. If you find 'PostgreSQL' hard to pronounce, call it
'Postgres' instead.

=== Who controls PostgreSQL? ===

If you are looking for a PostgreSQL gatekeeper, central committee, or
controlling company, give up --- there isn't one. We do have a core
committee and CVS committers, but these groups are more for
administrative purposes than control. The project is directed by the
community of developers and users, which anyone can join. All you need
to do is subscribe to the mailing lists and participate in the
discussions. (See the [[Developer FAQ|Developer's FAQ]] for information on how to get
involved in PostgreSQL development.)

=== Who is the PostgreSQL Global Development Group? ===

The "PGDG" is an international, unincorporated association of
individuals and companies who have contributed to the PostgreSQL
project. The PostgreSQL Core Team generally act as spokespeople
for the PGDG.

=== Who is the PostgreSQL Core Team? ===

A committee of five to seven (currently six) senior contributors to
PostgreSQL who do the following for the project: (a) set release dates,
(b) handle confidential matters for the project, (c) act as spokespeople
for the PGDG when required, and (d) arbitrate community decisions which
are not settled by consensus. The current Core Team is listed on top of
[http://www.postgresql.org/community/contributors/ the contributors page]

=== What about the various PostgreSQL foundations? ===

While the PostgreSQL project utilizes non-profit corporations in the
USA, Europe, Brazil and Japan for fundraising and project coordination,
these entities do not own the PostgreSQL code.

=== What is the license of PostgreSQL? ===

PostgreSQL is distributed under a license similar to BSD and MIT. Basically, it
allows users to do anything they want with the code, including
reselling binaries without the source code. The only restriction is
that you not hold us legally liable for problems with the software.
There is also the requirement that this copyright appear in all copies
of the software. Here is the license we use:

PostgreSQL Data Base Management System

Portions Copyright (c) 1996-2010, PostgreSQL Global Development Group
Portions Copyright (c) 1994-1996 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.

=== What platforms does PostgreSQL support? ===

In general, any modern Unix-compatible platform should be able to run
PostgreSQL. The platforms that have received recent explicit testing
can be seen in the [http://buildfarm.postgresql.org/ Build farm].
The documentation contains more details about supported platforms at http://www.postgresql.org/docs/current/static/supported-platforms.html.

PostgreSQL also runs natively on Microsoft Windows NT-based operating
systems like Win2000 SP4, WinXP, and Win2003. A prepackaged installer
is available at http://www.postgresql.org/download/windows.
MSDOS-based versions of Windows (Win95, Win98, WinMe) can run
PostgreSQL using Cygwin.

=== Where can I get PostgreSQL? ===

There are binary distributions for various operating systems and platforms; see [http://www.postgresql.org/download our download area].

The source code can be obtained [http://www.postgresql.org/ftp/ via web browser] or [ftp://ftp.postgresql.org/pub/ through ftp].

=== What is the most recent release? ===

The latest release of PostgreSQL is shown on the front page of [http://www.postgresql.org/ our website].

We typically have a major release every year, with minor releases every few months.
Minor releases are usually made at the same time for all supported major-release branches.
For more about major versus minor releases, see
http://www.postgresql.org/support/versioning.

=== Where can I get support? ===

The PostgreSQL community provides assistance to many of its users via
email. The main web site to subscribe to the email lists is
http://www.postgresql.org/community/lists/. The general or bugs lists
are a good place to start. For best results, consider reading the
[[guide to reporting problems]] before you post to make sure you
include enough information for people to help you.

The major IRC channel is #postgresql on Freenode (irc.freenode.net).
A Spanish one also
exists on the same network, (#postgresql-es), a French one,
(#postgresqlfr), and a Brazilian one, (#postgresql-br). There is also
a PostgreSQL channel on EFNet.

A list of support companies is available at
http://www.postgresql.org/support/professional_support.

=== How do I submit a bug report? ===

Visit the PostgreSQL bug form at
http://www.postgresql.org/support/submitbug to submit your bug
report to the pgsql-bugs mailing list. Also check out our ftp
site ftp://ftp.postgresql.org/pub/ to see if there is a more recent
PostgreSQL version.

For a prompt and helpful response, it is important for you to read the
[[guide to reporting problems]] to make sure that you include the
information required to fully understand and act on your report.

Bugs submitted using the bug form or posted to any PostgreSQL mailing
list typically generates one of the following replies:
* It is not a bug, and why
* It is a known bug and is already on the TODO list
* The bug has been fixed in the current release
* The bug has been fixed but is not packaged yet in an official release
* A request is made for more detailed information:
** Operating system
** PostgreSQL version
** Reproducible test case
** Debugging information
** [[Generating_a_stack_trace_of_a_PostgreSQL_backend|Debugger backtrace output]]
* The bug is new. The following might happen:
** A patch is created and will be included in the next major or minor release
** The bug cannot be fixed immediately and is added to the TODO list

=== How do I find out about known bugs or missing features? ===

PostgreSQL supports an extended subset of SQL:2003. See our [[Todo|TODO list]]
for known bugs, missing features, and future plans.

A feature request usually results in one of the following replies:
* The feature is already on the TODO list
* The feature is not desired because:
** It duplicates existing functionality that already follows the SQL standard
** The feature would increase code complexity but add little benefit
** The feature would be insecure or unreliable
* The new feature is added to the TODO list

PostgreSQL does not use a bug tracking system because we find it more
efficient to respond directly to email and keep the TODO list
up-to-date. In practice, bugs don't last very long in the software,
and bugs that affect a large number of users are fixed rapidly. The
only place to find all changes, improvements, and fixes in a
PostgreSQL release is to read the CVS log messages. Even the release
notes do not list every change made to the software.

=== A bug I'm encountering is fixed in a newer minor release of PostgreSQL, but I don't want to upgrade. Can I get a patch for just this issue? ===

No. Nobody will make a custom patch for you so you can (say) extract a fix from 8.4.3 and apply it to 8.4.1 .
That's because there should never be any need to do that.

PostgreSQL has a strict policy that only bug fixes are back-patched into point releases, as per the [http://www.postgresql.org/support/versioning version policy]. It is safe to upgrade from 8.4.1 to 8.4.3,
for example. Binary compatibility will be maintained, no dump and reload is required, nothing will break, but bugs that might
cause problems have been fixed. Even if you are not yet encountering a particular bug, you might later, and it is wise to upgrade promptly.
You just have to install the update and re-start the database server, nothing more.

Upgrading from 8.3 to 8.4, or 8.4 to 9.0, is a major upgrade that does not come with the same guarantees. However, if a bug
is discovered in 9.0 then it will generally be fixed in all maintained older versions like 8.4 and 8.3 if it is safe and
practical to do so.

This means that if you're running 8.1.0, upgrading to 8.1.21 is strongly recommended and very safe. On the other hand,
upgrading to the next major release, 8.2.x, may require changes to your app, and will certainly require a dump and reload.

If you want to be careful about all upgrades, you should read the [http://www.postgresql.org/docs/current/static/release.html release notes]
for each point release between your current one and the latest minor version of the same major release carefully. If you're
exceptionally paranoid about upgrades, you can fetch the source code to each set of point release changes from [http://git.postgresql.org/ PostgreSQL's git repository] and examine it.

It is strongly recommended that you always upgrade to the latest minor release. Avoid trying to extract and apply individual fixes
from point releases; by doing so you're bypassing all the QA done by the PostgreSQL team when they prepare a release, and are creating your
own custom version that nobody else has ever used. It's a lot safer to just update to the latest tested, safe release. Patching your own custom, non-standard build will also take more time/effort, and will require the same amount of downtime as a normal upgrade.

=== I have a program that says it wants PostgreSQL x.y.1. Can I use PostgreSQL x.y.2 instead? ===

Any program that works with a particular version, like 8.4.1, should work with any other minor version in the same major version. That means that if a program says it wants (eg) 8.4.1, you can and should install the latest in the 8.4 series instead.

See the previous question for more details.

=== What documentation is available? ===

PostgreSQL includes extensive documentation, including a large manual,
manual pages, and some test examples. See the /doc directory. You can
also browse the manuals online at http://www.postgresql.org/docs.

There are a number of PostgreSQL
books available for purchase; two of them are also available online. A list of books can be found at
http://www.postgresql.org/docs/books/. One of the most popular ones is the one by Korry & Susan
Douglas.

There is also a collection of
PostgreSQL technical articles on the
[[Community_Generated_Articles%2C_Guides%2C_and_Documentation | wiki]].

The command line client program psql has some \d commands to show
information about types, operators, functions, aggregates, etc. - use
\? to display the available commands.

=== How can I learn SQL? ===

First, consider the PostgreSQL-specific books mentioned above. Many of
our users also like The Practical SQL Handbook, Bowman, Judith S., et
al., Addison-Wesley. Others like The Complete Reference SQL, Groff et
al., McGraw-Hill.

Many people consider the PostgreSQL documentation to be an excellent guide
for learning SQL its self, as well as for PostgreSQL's implementation of it.
For best results use PostgreSQL alongside another full-featured SQL database as
you learn, so you get used to SQL without becoming reliant on PostgreSQL-specific
features. The PostgreSQL documentation generally mentions when features are PostgreSQL
extensions of the standard.

There are also many nice tutorials available online:
* 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
* http://sqlzoo.net

=== How do I submit a patch or join the development team? ===

See the [[Developer FAQ|Developer's FAQ]].

=== How does PostgreSQL compare to other DBMSs? ===

There are several ways of measuring software: features, performance,
reliability, support, and price.

==== Features ====

PostgreSQL has most features present in large proprietary DBMSs,
like transactions, subselects, triggers, views, foreign key
referential integrity, and sophisticated locking. We have some
features they do not have, like user-defined types,
inheritance, rules, and multi-version concurrency control to
reduce lock contention.

==== Performance ====

PostgreSQL's performance is comparable to other proprietary and
open source databases. It is faster for some things, slower for
others. Our performance is usually +/-10% compared to other databases.

==== Reliability ====

We realize that a DBMS must be reliable, or it is worthless. We
strive to release well-tested, stable code that has a minimum
of bugs. Each release has at least one month of beta testing,
and our release history shows that we can provide stable, solid
releases that are ready for production use. We believe we
compare favorably to other database software in this area.

==== Support ====

Our mailing lists provide contact with a large group of
developers and users to help resolve any problems encountered.
While we cannot guarantee a fix, proprietary DBMSs do not always
supply a fix either. Direct access to developers, the user
community, manuals, and the source code often make PostgreSQL
support superior to other DBMSs. There is commercial
per-incident support available for those who need it. (See [[#Where_can_I_get_support.3F | section 1.7]]).

==== Price ====

We are free for all use, both proprietary and open source.
You can add our code to your product with no limitations,
except those outlined in our BSD-style license stated above.

=== Can PostgreSQL be embedded? ===

PostgreSQL is designed as a client/server architecture, which requires
separate processes for each client and server, and various helper
processes. Many embedded architectures can support such requirements.
However, if your embedded architecture requires the database server to
run inside the application process, you cannot use Postgres and should
select a lighter-weight database solution.

Popular embeddable options include [http://sqlite.org SQLite] and [http://firebirdsql.org Firebird SQL].

=== How do I unsubscribe from the PostgreSQL email lists? How do I avoid receiving duplicate emails? ===

The PostgreSQL Majordomo page allows subscribing or unsubscribing from
any of the PostgreSQL email lists. (You might need to have your
Majordomo password emailed to you to log in.)

All PostgreSQL email lists are configured so a group reply goes to the
email list and the original email author. This is done so users
receive the quickest possible email replies. If you would prefer not
to receive duplicate email from the list in cases where you already
receive an email directly, check eliminatecc from the Majordomo Change
Settings page. You can also prevent yourself from receiving copies of
emails you post to the lists by unchecking selfcopy.

== User Client Questions ==

=== What interfaces are available for PostgreSQL? ===

The PostgreSQL install includes only the C and embedded C interfaces.
All other interfaces are independent projects that are downloaded
separately; being separate allows them to have their own release
schedule and development teams.

Some programming languages like PHP include an interface to
PostgreSQL. Interfaces for languages like Perl, TCL, Python, and many
others are available at http://pgfoundry.org.

=== What tools are available for using PostgreSQL with Web pages? ===

A nice introduction to Database-backed Web pages can be seen at:
http://www.webreview.com

For Web integration, PHP (http://www.php.net) is an excellent
interface.

For complex cases, many use the Perl and DBD::Pg with CGI.pm or
mod_perl.

=== Does PostgreSQL have a graphical user interface? ===

There are a large number of GUI Tools that are available for
PostgreSQL from both proprietary and open source developers. A detailed
list can be found in the [[Community Guide to PostgreSQL GUI Tools]].

== Administrative Questions ==

=== How do I install PostgreSQL somewhere other than /usr/local/pgsql? ===

Specify the --prefix option when running configure.

=== I'm installing PostgreSQL and don't know the password for the postgres user ===

Dave Page wrote a [http://pgsnake.blogspot.com/2010/07/postgresql-passwords-and-installers.html blog post] explaining what the different passwords are used for, and how to overcome common problems such as resetting them.

=== How do I control connections from other hosts? ===

By default, PostgreSQL only allows connections from the local machine
using Unix domain sockets or TCP/IP connections. Other machines will
not be able to connect unless you modify listen_addresses in the
postgresql.conf file, enable host-based authentication by modifying
the $PGDATA/pg_hba.conf file, and restart the database server.

=== How do I tune the database engine for better performance? ===

There are three major areas for potential performance improvement:

==== Query Changes ====
This involves modifying queries to obtain better performance:

* Creation of indexes, including expression and partial indexes
* Use of COPY instead of multiple INSERTs
* Grouping of multiple statements into a single transaction to reduce commit overhead
* Use of CLUSTER when retrieving many rows from an index
* Use of LIMIT for returning a subset of a query's output
* Use of Prepared queries
* Use of ANALYZE to maintain accurate optimizer statistics
* Regular use of VACUUM or pg_autovacuum
* Dropping of indexes during large data changes

==== Server Configuration ====
A number of postgresql.conf settings affect performance. For
more details, see Administration Guide/Server Run-time
Environment/Run-time Configuration.

==== Hardware Selection ====
The effect of hardware on performance is detailed in
http://www.powerpostgresql.com/PerfList/ and
http://momjian.us/main/writings/pgsql/hw_performance/index.html.

=== What debugging features are available? ===

There are many log_* server configuration variables at http://www.postgresql.org/docs/current/interactive/runtime-config-logging.html that enable printing of query and process statistics which can be very useful for debugging and performance measurements.

=== Why do I get "Sorry, too many clients" when trying to connect? ===

You have reached the default limit of 100 database sessions. You need
to increase the server's limit on how many concurrent backend
processes it can start by changing the max_connections value in
postgresql.conf and restarting the server.

=== What is the upgrade process for PostgreSQL? ===

See http://www.postgresql.org/support/versioning for a general
discussion about upgrading, and
http://www.postgresql.org/docs/current/static/install-upgrading.html
for specific instructions.

=== Will PostgreSQL handle recent daylight saving time changes in various countries? ===

PostgreSQL releases 8.0 and up depend on the widely-used tzdata database
(also called the zoneinfo database or the [http://www.twinsun.com/tz/tz-link.htm Olson timezone database]) for
daylight savings information. To deal with a DST law change that affects you,
install a new tzdata file set and restart the server.

All PostgreSQL update releases include the latest available tzdata files,
so keeping up-to-date on minor releases for your major version is usually
sufficient for this.

On platforms that receive regular software updates including new tzdata files,
it may be more convenient to rely on the system's copy of the tzdata files.
This is possible as a compile-time option. Most Linux distributions choose
this approach for their pre-built versions of PostgreSQL.

PostgreSQL releases before 8.0 always rely on the operating system's timezone
information.

=== What computer hardware should I use? ===

Because PC hardware is mostly compatible, people tend to believe that
all PC hardware is of equal quality. It is not. ECC RAM, SCSI, and
quality motherboards are more reliable and have better performance
than less expensive hardware. PostgreSQL will run on almost any
hardware, but if reliability and performance are important it is wise
to research your hardware options thoroughly.

Database servers, unlike many other applications, are usually I/O and memory constrained, so it is wise to focus on the I/O subsystem first, then memory capacity, and lastly consider CPU issues. For example, a disk controller with a
battery-backed cache is often the cheapest and easiest way to improve database performance. Our email lists can be used to discuss hardware options and tradeoffs.

=== How does PostgreSQL use CPU resources? ===

The PostgreSQL server is process-based (not threaded), and uses one operating system process per database session. A single database session (connection) cannot utilize more than one CPU. Of course, multiple sessions are automatically spread across all available CPUs by your operating system. Client applications can easily use threads and create multiple database connections from each thread.

A single complex and CPU-intensive query is unable to use more than one CPU to do the processing for the query. The OS may still be able to use others for disk I/O etc, but you won't see much benefit from more than one spare core.

=== Why does PostgreSQL have so many processes, even when idle? ===

As noted in [[FAQ#How does PostgreSQL use CPU resources?|the answer above]], PostgreSQL is process based, so it starts one <code>postgres</code> (or <code>postgres.exe</code> on Windows) instance per connection. The postmaster (which accepts connections and starts new postgres instances for them) is always running. In addition, PostgreSQL generally has one or more "helper" processes like the stats collector, background writer, autovacuum daemon, walsender, etc, all of which show up as "postgres" instances in most system monitoring tools.

Despite the number of processes, they actually use very little in the way of real resources. See [[FAQ#Why does PostgreSQL show up as using so much memory in my system monitoring tool?|the next answer]].

=== Why does PostgreSQL use so much memory? ===

Despite appearances, this is absolutely normal, and there's actually nowhere near as much memory being used as tools like <code>top</code> or the Windows process monitor say PostgreSQL is using.

Tools like <code>top</code> and the Windows process monitor may show many <code>postgres</code> instances (see above), each of which appears to use a huge amount of memory. Often, when added up, the amount the postgres instances use is many times the amount of memory actually installed in the computer!

This is a consequence of how these tools report memory use. They generally don't understand shared memory very well, and show it as if it was memory used individually and exclusively by each postgres instance. PostgreSQL uses a big chunk of shared memory to communicate between its backends and cache data. Because these tools count that shared memory block once per <code>postgres</code> instance instead of counting it once for all <code>postgres</code> instances, they massively over-estimate how much memory PostgreSQL is using.

== Operational Questions ==

=== How do I SELECT only the first few rows of a query? A random row? ===

To retrieve only a few rows, if you know at the number of rows needed
at the time of the SELECT use LIMIT . If an index matches the ORDER BY
it is possible the entire query does not have to be executed. If you
don't know the number of rows at SELECT time, use a cursor and FETCH.

To SELECT a random row, use:
SELECT col
FROM tab
ORDER BY random()
LIMIT 1;

See also this [http://blog.rhodiumtoad.org.uk/2009/03/08/selecting-random-rows-from-a-table/ blog entry by Andrew Gierth]
that has more information on this topic.

=== How do I find out what tables, indexes, databases, and users are defined? How do I see the queries used by psql to display them? ===

Use the \dt command to see tables in psql. For a complete list of
commands inside psql you can use \?. Alternatively you can read the
source code for psql in file pgsql/src/bin/psql/describe.c, it
contains SQL commands that generate the output for psql's backslash
commands. You can also start psql with the -E option so it will print
out the queries it uses to execute the commands you give. PostgreSQL
also provides an SQL compliant INFORMATION SCHEMA interface you can
query to get information about the database.

There are also system tables beginning with pg_ that describe these
too.

Use psql -l will list all databases.

Also try the file pgsql/src/tutorial/syscat.source. It illustrates
many of the SELECTs needed to get information from the database system
tables.

=== How do you change a column's data type? ===

Changing the data type of a column can be done easily in 8.0 and later
with ALTER TABLE ALTER COLUMN TYPE.

In earlier releases, do this:
BEGIN;
ALTER TABLE tab ADD COLUMN new_col new_data_type;
UPDATE tab SET new_col = CAST(old_col AS new_data_type);
ALTER TABLE tab DROP COLUMN old_col;
COMMIT;

You might then want to do VACUUM FULL tab to reclaim the disk space
used by the expired rows.

=== What is the maximum size for a row, a table, and a database? ===

These are the limits:

Maximum size for a database? unlimited (32 TB databases exist)
Maximum size for a table? 32 TB
Maximum size for a row? 400 GB
Maximum size for a field? 1 GB
Maximum number of rows in a table? unlimited
Maximum number of columns in a table? 250-1600 depending on column types
Maximum number of indexes on a table? unlimited

Of course, these are not actually unlimited, but limited to available
disk space and memory/swap space. Performance may suffer when these
values get unusually large.

The maximum table size of 32 TB does not require large file support
from the operating system. Large tables are stored as multiple 1 GB
files so file system size limits are not important.

The maximum table size, row size, and maximum number of columns can be
quadrupled by increasing the default block size to 32k. The maximum
table size can also be increased using table partitioning.

One limitation is that indexes can not be created on columns longer
than about 2,000 characters. Fortunately, such indexes are rarely
needed. Uniqueness is best guaranteed by a function index of an MD5
hash of the long column, and full text indexing allows for searching
of words within the column.

=== How much database disk space is required to store data from a typical text file? ===

A PostgreSQL database may require up to five times the disk space to
store data from a text file.

As an example, consider a file of 100,000 lines with an integer and
text description on each line. Suppose the text string averages
twenty bytes in length. The flat file would be 2.8 MB. The size of the
PostgreSQL database file containing this data can be estimated as 5.2
MB:
24 bytes: each row header (approximate)
24 bytes: one int field and one text field
+ 4 bytes: pointer on page to tuple
----------------------------------------
52 bytes per row

The data page size in PostgreSQL is 8192 bytes (8 KB), so:

8192 bytes per page
------------------- = 158 rows per database page (rounded down)
52 bytes per row

100000 data rows
------------------ = 633 database pages (rounded up)
158 rows per page

633 database pages * 8192 bytes per page = 5,185,536 bytes (5.2 MB)

Indexes do not require as much overhead, but do contain the data that
is being indexed, so they can be large also.

NULLs are stored as bitmaps, so they use very little space.

Note that long values may be compressed transparently.

See also this presentation on the topic: [[Image:How_Long_Is_a_String.pdf]].

=== Why are my queries slow? Why don't they use my indexes? ===

Indexes are not used by every query. Indexes are used only if the
table is larger than a minimum size, and the query selects only a
small percentage of the rows in the table. This is because the random
disk access caused by an index scan can be slower than a straight read
through the table, or sequential scan.

To determine if an index should be used, PostgreSQL must have
statistics about the table. These statistics are collected using
VACUUM ANALYZE, or simply ANALYZE. Using statistics, the optimizer
knows how many rows are in the table, and can better determine if
indexes should be used. Statistics are also valuable in determining
optimal join order and join methods. Statistics collection should be
performed periodically as the contents of the table change.

Indexes are normally not used for ORDER BY or to perform joins. A
sequential scan followed by an explicit sort is usually faster than an
index scan of a large table. However, LIMIT combined with ORDER BY
often will use an index because only a small portion of the table is
returned.

If you believe the optimizer is incorrect in choosing a sequential
scan, use SET enable_seqscan TO 'off' and run query again to see if an
index scan is indeed faster.

When using wild-card operators such as LIKE or ~, indexes can only be
used in certain circumstances:

* The beginning of the search string must be anchored to the start of the string, i.e.
** LIKE patterns must not start with % or _.
** ~ (regular expression) patterns must start with ^.

* The search string can not start with a character class, e.g. [a-e].

* Case-insensitive searches such as ILIKE and ~* do not utilize indexes. Instead, use expression indexes, which are described in [[#How_do_I_perform_regular_expression_searches_and_case-insensitive_regular_expression_searches.3F_How_do_I_use_an_index_for_case-insensitive_searches.3F | section 4.8]].

* C locale must be used during initdb because sorting in a non-C locale often doesn't match the behavior of LIKE. You can create a special text_pattern_ops index that will work in such cases, but note it is only helpful for LIKE indexing.

It is also possible to use full text indexing for word searches.

The [[SlowQueryQuestions]] article contains some more tips and guidance.

=== How do I see how the query optimizer is evaluating my query? ===

This is done with the EXPLAIN command; see [[Using EXPLAIN]].

=== How do I change the sort ordering of textual data? ===

PostgreSQL sorts textual data according to the ordering that is defined by the current locale, which is selected during initdb.
(In 8.4 and up it will be possible to select a different locale when creating a new database.)
If you don't like the ordering then you need to use a different locale.
In particular, most locales other than "C" sort according to dictionary order, which largely ignores punctuation and spacing.
If that's not what you want then you need "C" locale.

=== How do I perform regular expression searches and case-insensitive regular expression searches? How do I use an index for case-insensitive searches? ===

The ~ operator does regular expression matching, and ~* does
case-insensitive regular expression matching. The case-insensitive
variant of LIKE is called ILIKE.

Case-insensitive equality comparisons are normally expressed as:
SELECT *
FROM tab
WHERE lower(col) = 'abc';

This will not use a standard index on "col". However, if you create an
expression index on "lower(col)", it will be used:
CREATE INDEX tabindex ON tab (lower(col));

If the above index is created as UNIQUE, then the column can store
upper and lowercase characters, but it cannot contain identical values that
differ only in case. To force a particular case to be stored in the
column, use a CHECK constraint or a trigger.

In PostgreSQL 8.4 and later, you can also use the contributed [http://www.postgresql.org/docs/8.4/static/citext.html CITEXT data type], which internally implements the "lower()" calls, so that you can effectively treat it as a fully case-insensitive data type. CITEXT is also [https://svn.kineticode.com/citext/trunk/ available for 8.3], and an earlier version that treats only ASCII characters case-insensitively on 8.2 and earlier is available on [http://pgfoundry.org/projects/citext/ pgFoundry].

=== In a query, how do I detect if a field is NULL? How do I concatenate possible NULLs? How can I sort on whether a field is NULL or not? ===

You can test the value with IS NULL or IS NOT NULL, like this:
SELECT *
FROM tab
WHERE col IS NULL;

Concatenating a NULL with something else produces another NULL.
If that's not what you want, you can replace the NULL(s) using
COALESCE(), like this:
<nowiki>SELECT COALESCE(col1, '') || COALESCE(col2, '')</nowiki>
FROM tab;

To sort by the NULL status, use an IS NULL or IS NOT NULL test
in your ORDER BY clause. Things that are true will sort higher than
things that are false, so the following will put NULL entries at the
front of the output:
SELECT *
FROM tab
ORDER BY (col IS NOT NULL), col;

In PostgreSQL 8.3 and up, you can also control sort ordering of NULLs
using the recently-standardized NULLS FIRST/NULLS LAST modifiers,
like this:
SELECT *
FROM tab
ORDER BY col NULLS FIRST;

=== What is the difference between the various character types? ===

{| border="1"
!Type
!Internal Name
!Notes
|-
|VARCHAR(n)
|varchar
|size specifies maximum length, no padding
|-
|CHAR(n)
|bpchar
|blank-padded to the specified fixed length
|-
|TEXT
|text
|no specific upper limit on length
|-
|BYTEA
|bytea
|variable-length byte array (null-byte safe)
|-
|"char" (with the quotes)
|char
|one byte
|}

You will see the internal name when examining system catalogs and in
some error messages.

The first four types above are "varlena" types (i.e., the field length
is explicitly stored on disk, followed by the data). Thus the actual
space used is slightly greater than the expected size. However, long
values are also subject to compression, so the space on disk might
also be less than expected.

VARCHAR(n) is best when storing variable-length strings if a specific
upper limit on the string length is required by the application.
TEXT is for strings of "unlimited" length (though all fields in PostgreSQL
are subject to a maximum value length of one gigabyte).

CHAR(n) is for storing strings that are all the same length. CHAR(n)
pads with blanks to the specified length, while VARCHAR(n) only stores
the characters supplied. BYTEA is for storing binary data,
particularly values that include zero bytes. All these types have similar
performance characteristics, except that the blank-padding involved
in CHAR(n) requires additional storage and some extra runtime.

The "char" type (the quotes are required to distinguish it from CHAR(n))
is a specialized datatype that can store exactly one byte. It is found in
the system catalogs but its use in user tables is generally discouraged.

=== How do I create a serial/auto-incrementing field? ===

PostgreSQL supports a SERIAL data type. Actually, this isn't quite
a real type. It's a shorthand for creating an integer column that
is fed from a sequence.

For example, this:
CREATE TABLE person (
id SERIAL,
name TEXT
);
is automatically translated into this:
CREATE SEQUENCE person_id_seq;
CREATE TABLE person (
id INTEGER NOT NULL DEFAULT nextval('person_id_seq'),
name TEXT
);

The automatically created sequence is named ''table''_''serialcolumn''_seq,
where ''table'' and ''serialcolumn'' are the names of the table and SERIAL
column, respectively. See the CREATE SEQUENCE manual page for more
information about sequences.

There is also BIGSERIAL, which is like SERIAL except that the resulting
column is of type BIGINT instead of INTEGER. Use this type if you think
that you might need more than 2 billion serial values over the lifespan
of the table.

=== How do I get the value of a SERIAL insert? ===

The simplest way is to retrieve the assigned SERIAL value with
RETURNING. Using the example table in the previous question, it would look like this:
INSERT INTO person (name) VALUES ('Blaise Pascal') RETURNING id;

You can also call nextval() and use that value in the INSERT, or call
currval() after the INSERT.

=== Doesn't currval() lead to a race condition with other users? ===

No. currval() returns the latest sequence value assigned by your session,
independently of what is happening in other sessions.

=== Why are there gaps in the numbering of my sequence/SERIAL column? Why aren't my sequence numbers reused on transaction abort? ===

To improve concurrency, sequence values are given out to running
transactions on-demand; the sequence object is not kept locked but is
immediately available for another transaction to get another sequence
value. This causes gaps in numbering from aborted transactions.

=== What is an OID? ===

If a table is created WITH OIDS, each row includes an OID column that is automatically filled in during INSERT.
OIDs are sequentially assigned 4-byte integers. Initially they are unique
across the entire installation. However, the OID counter wraps around at 4 billion,
and after that OIDs may be duplicated.

It is possible to prevent duplication of OIDs within a single table by
creating a unique index on the OID column (but note that the WITH OIDS
clause doesn't by itself create such an index).
The system checks the index to see if a newly
generated OID is already present, and if so generates a new OID and
repeats. This works well so long as no OID-containing table has
more than a small fraction of 4 billion rows.

PostgreSQL uses OIDs for object identifiers in the system catalogs,
where the size limit is unlikely to be a problem.

To uniquely number rows in user tables, it is best to use SERIAL
rather than an OID column, or BIGSERIAL if the table is expected to
have more than 2 billion entries over its lifespan.

=== What is a CTID? ===

CTIDs identify specific physical rows by their block and
offset positions within a table.
They are used by index entries to point to physical rows.
A logical row's CTID changes when it is updated, so the CTID
cannot be used as a long-term row identifier. But it is sometimes
useful to identify a row within a transaction when no competing
update is expected.

=== Why do I get the error "ERROR: Memory exhausted in AllocSetAlloc()"? ===

You probably have run out of virtual memory on your system, or your
kernel has a low limit for certain resources. Try this before starting
the server:
ulimit -d 262144
limit datasize 256m

Depending on your shell, only one of these may succeed, but it will
set your process data segment limit much higher and perhaps allow the
query to complete. This command applies to the current process, and
all subprocesses created after the command is run. If you are having a
problem with the SQL client because the backend is returning too much
data, try it before starting the client.

=== How do I tell what PostgreSQL version I am running? ===

Run this query: SELECT version();

=== Is there a way to leave an audit trail of database operations? ===

There's nothing built-in, but it's not too difficult to build such
facilities yourself.

Simple example right in the official docs:
http://www.postgresql.org/docs/8.3/static/plpgsql-trigger.html#PLPGSQL-TRIGGER-AUDIT-EXAMPLE

Project targeting this feature: http://pgfoundry.org/projects/tablelog/

Background information and other sample implementations:
http://it.toolbox.com/blogs/database-soup/simple-data-auditing-19014
http://www.go4expert.com/forums/showthread.php?t=7252
http://www.alberton.info/postgresql_table_audit.html

=== How do I create a column that will default to the current time? ===

Use CURRENT_TIMESTAMP:
CREATE TABLE test (x int, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

=== How do I perform an outer join? ===

PostgreSQL supports outer joins using the SQL standard syntax. Here
are two examples:
SELECT *
FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col);

or
SELECT *
FROM t1 LEFT OUTER JOIN t2 USING (col);

These identical queries join t1.col to t2.col, and also return any
unjoined rows in t1 (those with no match in t2). A RIGHT join would
add unjoined rows of t2. A FULL join would return the matched rows
plus all unjoined rows from t1 and t2. The word OUTER is optional and
is assumed in LEFT, RIGHT, and FULL joins. Ordinary joins are called
INNER joins.

=== How do I perform queries using multiple databases? ===

There is no way to query a database other than the current one.
Because PostgreSQL loads database-specific system catalogs, it is
uncertain how a cross-database query should even behave.

contrib/dblink allows cross-database queries using function calls. Of
course, a client can also make simultaneous connections to different
databases and merge the results on the client side.

=== How do I return multiple rows or columns from a function? ===

It is easy using set-returning functions,
[[Return more than one row of data from PL/pgSQL functions]].

=== Why do I get "relation with OID ##### does not exist" errors when accessing temporary tables in PL/PgSQL functions? ===

In PostgreSQL versions < 8.3, PL/PgSQL caches function scripts, and an
unfortunate side effect is that if a PL/PgSQL function accesses a
temporary table, and that table is later dropped and recreated, and
the function called again, the function will fail because the cached
function contents still point to the old temporary table. The solution
is to use EXECUTE for temporary table access in PL/PgSQL. This will
cause the query to be reparsed every time.

This problem does not occur in PostgreSQL 8.3 and later.

=== What replication solutions are available? ===

Though "replication" is a single term, there are several technologies
for doing replication, with advantages and disadvantages for each.
Our documentation contains a good introduction to this topic at
http://www.postgresql.org/docs/8.3/static/high-availability.html and a
grid listing replication software and features is at
[[Replication, Clustering, and Connection Pooling]]

Master/slave replication allows a single master to receive read/write
queries, while slaves can only accept read/SELECT queries. The most
popular freely available master-slave PostgreSQL replication solution
is Slony-I.

Multi-master replication allows read/write queries to be sent to
multiple replicated computers. This capability also has a severe
impact on performance due to the need to synchronize changes between
servers. PGCluster is the most popular such solution freely available
for PostgreSQL.

There are also proprietary and hardware-based replication solutions
available supporting a variety of replication models.

=== Is possible to create a shared-storage postgresql server cluster? ===

PostgreSQL does not support clustering using [[Shared_Storage|shared storage]] on a SAN, SCSI backplane,
iSCSI volume, or other shared media. Such "RAC-style" clustering isn't supported.
Only replication-based clustering is currently supported.

See [[Replication, Clustering, and Connection Pooling]] information for details.

[[Shared_Storage|Shared-storage]] 'failover' is possible, but it is not safe to have more than one
postmaster running and accessing the data store at the same time. Heartbeat and
[http://en.wikipedia.org/wiki/STONITH STONITH] or some other hard-disconnect option are recommended.

=== Why are my table and column names not recognized in my query? Why is capitalization not preserved? ===

The most common cause of unrecognized names is the use of
double-quotes around table or column names during table creation. When
double-quotes are used, table and column names (called identifiers)
are stored case-sensitive, meaning you must use double-quotes when
referencing the names in a query. Some interfaces, like pgAdmin,
automatically double-quote identifiers during table creation. So, for
identifiers to be recognized, you must either:

* Avoid double-quoting identifiers when creating tables
* Use only lowercase characters in identifiers
* Double-quote identifiers when referencing them in queries

=== I lost the database password. What can I do to recover it? ===

You can't. However, you can reset it to something else. To do this, you

* edit pg_hba.conf to allow ''trust'' authorization temporarily
* Reload the config file (pg_ctl reload)
* Connect and issue ALTER ROLE / PASSWORD to set the new password
* edit pg_hba.conf again and restore the previous settings
* Reload the config file again

=== Does PostgreSQL have stored procedures? ===

PostgreSQL doesn't. However PostgreSQL have very powerful functions and user-defined functions capabilities that can do most things that other RDBMS stored routines (procedures and functions) can do and in many cases more.

These functions can be of different types and can be implemented in several programming languages.
(Refer to documentation for more details. [http://www.postgresql.org/docs/current/static/xfunc.html User-Defined Functions])

PostgreSQL functions can be invoked in many ways. If you want to invoke a function as you would call a stored procedure in other RDBMS (typically a function with side-effects but whose result you don't care for example because it returns void), one option would be to use [http://www.postgresql.org/docs/current/static/plpgsql.html PL/pgSQL Language] for your procedure and the [http://www.postgresql.org/docs/current/static/plpgsql-statements.html#PLPGSQL-STATEMENTS-SQL-NORESULT PERFORM] command. Example:
PERFORM theNameOfTheFunction(arg1, arg2);

Note that invoking instead:
SELECT theNameOfTheFunction(arg1, arg2);
would produce a result even if the function returns void (this result would be one row containing a void value).

[http://www.postgresql.org/docs/current/static/plpgsql-statements.html#PLPGSQL-STATEMENTS-SQL-NORESULT PERFORM] could thus be used to discard this unuseful result.

The main limitations on Pg's stored functions - as compared to true stored procedures - are:

* inability to return multiple result sets
* no support for autonomous transactions (<code>BEGIN</code>, <code>COMMIT</code> and <code>ROLLBACK</code> within a function)
* no support for the SQL-standard <code>CALL</code> syntax, though the ODBC and JDBC drivers will translate calls for you.

=== Why don't BEGIN, ROLLBACK and COMMIT work in stored procedures/functions? ===

PostgreSQL doesn't support autonomous transactions in its stored functions. Like all PostgreSQL queries, stored functions always run in a transaction and cannot operate outside a transaction.

If you need a stored procedure to manage transactions, you can look into the dblink interface or do the work from a client-side script instead. In some cases you can do what you need to using [http://www.postgresql.org/docs/current/static/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING exception blocks in PL/PgSQL], because each BEGIN/EXCEPTION/END block creates a subtransaction.

=== Why is "SELECT count(*) FROM bigtable;" slow? ===

It can't be answered directly from an index. PostgreSQL has to check the visibility for each record, so it
forces a sequential scan of the entire table. If you want, you can keep track of the number of rows yourself with triggers, but beware that this will slow down write access to the table.

You can get an estimation. The reltuples column in [http://www.postgresql.org/docs/current/static/catalog-pg-class.html pg_class] contains the information from the latest [http://www.postgresql.org/docs/current/static/sql-analyze.html ANALYZE] of the table. On a large table this is often accurate to within a few thousandths of a percent, which is accurate enough for many purposes.

An "exact" count is often not exact for very long, anyway; due to [http://www.postgresql.org/docs/current/static/mvcc-intro.html MVCC] concurrency, the count will be accurate as of the moment the SELECT count(*) query (or, for stricter [http://www.postgresql.org/docs/current/static/transaction-iso.html transaction isolation] levels, its transaction) ''started'', and may well be out-of-date by the time the query completes. In a transaction mix where the table is being modified, two count(*) executions which return at the same moment might have different values, if a modifying transaction committed between their start times.

For more information, see [[Slow Counting]].

=== Why is my query much slower when run as a prepared query? ===

When PostgreSQL has the full query with all parameters known by planning time, it can use statistics in the table to find out if the values used in the query are very common or very uncommon in a column. This lets it change the way it fetches the data to be more efficient, as it knows to expect lots or very few results from a certain part of the query. For example, it might choose an sequential scan instead of doing an index scan if you search for 'active=y' and it knows that 99% of the records in the table have 'active=y', because in this case a sequential scan will be much faster.

In a prepared query, PostgreSQL doesn't have the value of all parameters when it's creating the plan. It has to try to pick a "safe" plan that should work fairly well no matter what value you supply as the parameter when you execute the prepared query. Unfortunately, this plan might not be very appropriate if the value you supply is vastly more common, or vastly less common, than is average for some randomly selected values in the table.

If you suspect this issue is affecting you, start by using the [http://www.postgresql.org/docs/current/static/sql-explain.html EXPLAIN] command to compare the slow and fast queries. Look at the output of <code>EXPLAIN SELECT query...</code> and compare it to the result of <code>PREPARE query... ; EXPLAIN EXECUTE query...</code> to see if the plans are notably different. <code>EXPLAIN ANALYZE</code> may give you more information, such as row count estimates and counts.

Usually people having this problem are trying to use prepared queries as a security measure to prevent SQL injection, rather than as a performance tuning option for expensive-to-plan queries frequently executed with a variety of different parameters. Those people should consider using client-side prepared statements if their client interface (eg PgJDBC) supports it.

At present, PostgreSQL does not offer a way to request re-planning of a prepared statement using a particular set of parameter values; doing so somewhat defeats the purpose of server-side prepared statements. Running a statistics check to see if a particular parameter value is notably outside the norm and automatically re-planning in that case has been discussed, but not agreed upon or implemented as yet.

See [[Using_EXPLAIN]]. If you're going to ask for help on the mailing lists, please read the [[Guide to reporting problems]].

=== Why is my query much slower when run in a function than standalone? ===

See [[FAQ#Why is my query much slower when run as a prepared query?]]. Queries in PL/PgSQL functions are prepared and cached, so they execute in much the same way as if you'd <code>PREPARE</code>d then <code>EXECUTE</code>d the query yourself.

If you're having really severe issues with this that improving the table statistics or adjusting your query don't help with, you can work around it by forcing PL/PgSQL to re-prepare your query at every execution. To do this, use the <code>EXECUTE ... USING</code> statement in PL/PgSQL to supply your query as a textual string. Alternately, the [http://www.postgresql.org/docs/current/static/functions-string.html quote_literal or quote_nullable] functions may be used to escape parameters substituted into query text.

[[Category:FAQ]]