PostgreSQL wiki - New pages [en]

Oscon 2013 signup

2013-05-18T00:25:21Z

Markwkm: oscon 2013 booth signup

* Time slots are intended to allow people to have enough time to go to a session before it starts and to come to the booth after a session ends for people attending the conference.

== Tue July 23 (17:00-18:00) (5pm - 6pm) - Opening Reception ==
* Mark Wong (markwkm at postgresql.org)

== Wed July 24 (10:00-16:30) (10am-4:40pm) ==

=== 10:00 - 11:15 ===
*
*

=== 11:15 - 12:50 LUNCH ===
*
*

=== 12:50 - 14:25 LUNCH ===
*
*

=== 14:25 - 15:15 ===
*
*

=== 15:15 - 16:40 ===
*
*

== Thurs July 19 10:00 - 17:00 (10am-5pm) ==

=== 10:00 - 11:25 ===
*
*

=== 11:25 - 12:50 LUNCH ===
*
*

=== 12:50 - 14:25 LUNCH ===
*
*

=== 14:25 - 16:00 ===
*
*

=== 16:00 - 17:00 ===
*
*

----

Thanks for participating!

[[Category:PostgreSQL Events]]

GSoC 2014

2013-05-14T18:45:57Z

Heikki:

This page is for collecting ideas for future Summer of Code projects. For the currently active Summer of Code program, see [[GSoC_2013]]

== Project Ideas ==

Project ideas are to be added here.

(Please can we have visibility of ideas on Hackers please to avoid overreaching what is possible in the time, and also working on dubious projects.)

=== Core ===
* UPDATE ... RETURNING OLD [http://www.postgresql.org/message-id/20130218171259.GA26999@fetter.org link]
* Add RETURNING to DDL (CREATE, ALTER, DROP) and possibly DCL (GRANT, REVOKE) [http://www.postgresql.org/message-id/20130218171259.GA26999@fetter.org link]
* Allow different datatypes to be sliced differently, when TOASTed [http://www.postgresql.org/message-id/CA+U5nMJGgJNt5VXqkR=crtDqXFmuyzwEF23-fD5NuSns+6N5dA@mail.gmail.com link]

=== Extensions ===
* cube extension improvements (indexing, type support, new KNN search metrics) [http://www.postgresql.org/message-id/6A7E75B1-64DD-4F5F-A991-435E3E5A24FB@gmail.com link]

=== Tools ===
* Rewrite (add) pg_dump and pg_restore utilities as libraries (.so, .dll & .dylib) [http://www.postgresql.org/message-id/1811491181.20130215163950@gf.microolap.com link]
* Extending MADlib functions to fill in (extrapolate) missing values in data sets [http://www.postgresql.org/message-id/B654BEBE-32D9-4670-BBB7-BC846AE5B785@gmail.com link1] [http://www.postgresql.org/message-id/511E7193.4020907@agliodbs.com link2]
* pg_upgrade support for Debian's pg_upgradecluster [http://www.postgresql.org/message-id/20130218213711.GA1005@awork2.anarazel.de link]

[[Category:Google Summer of Code]]

PgconfEU2013RoomSharing

2013-05-13T15:46:45Z

Mha: Created page with "= Room Sharing Requests: PGConf.EU 2013 = Please place your room sharing requests below. Suggested syntax is: * Name: Arrival - Departure, Room Booked? ** Obfuscated Email ** …"

= Room Sharing Requests: PGConf.EU 2013 =

Please place your room sharing requests below. Suggested syntax is:

* Name: Arrival - Departure, Room Booked?
** Obfuscated Email
** Notes

e.g.

* Josh Berkus: Oct 23 - 28, booked room
** josh - at - postgresql.org
** Speaker, non-smoking

(note, I am not actually looking for a room)

== Conrad Dublin ==

== Other Venues ==

Parallel Sort

2013-05-10T15:30:07Z

Rhaas: /* Dynamic Shared Memory */ fix tense

== Overview ==

If we could perform large sorts in parallel, we could make queries, and more importantly index builds, run faster. Also, it would be useful infrastructure for supporting general [[Parallel Query Execution]]. We imagine that the user backend will be supported by one or more "worker backends" which will be similar to a normal backend, but with no client connection. In broad terms, we expect them to look a lot like autovacuum worker processes, but with some differences: each will be associated with a user backend, and data will be passed back and forth between the user backend and its workers, and possibly among workers, sometimes in large volumes.

== Process Management and IPC ==

=== Dynamic Shared Memory ===

Shared memory is much faster than any other IPC mechanism, because it allows data to be passed between processes without kernel involvement. However, the shared memory segment we currently create isn't suitable for parallel execution, because its size is fixed at startup and can't easily be changed. We propose to introduce a mechanism for backends to create dynamic shared memory segments using shm_open(), CreateSharedMemory(), or similar APIs that will allow the user backend and its workers to map the same shared memory segment (possibly at different addresses).

=== Worker Backends ===

For simplicity, it seems best to maintain the invariant that all backends are direct children of the postmaster. Therefore, a user backend wanting workers will request that the postmaster start them, rather than starting them directly. Postmaster involvement must however be kept to a minimum to maintain system stability.

== InParallel Mode ==

Before beginning parallel operation, the user backend will set a flag in backend-local memory which will prohibit certain backend state changes that are unsafe in parallel mode. Worker backends will set this flag throughout their lifespan, prohibiting the same operations. After setting this flag, the user backend will transfer its state to the worker backends by writing it into a dynamic shared memory segment which will be read by the worker backends. Several different types of state will need to be transferred.

=== GUCs ===

The values of all GUCs will be transfered from the user backend to worker backends. Changes to GUCs will be prohibited while the InParallel flag is set, with the exception of temporary changes that will be reverted, such as entering a function with proconfig set.

=== Snapshot and Transaction State ===

The user backend will need to transfer its snapshot and transaction state stack to worker backends. Entering or exiting subtransactions, assigning XIDs, or updating the active snapshot will be prohibited while InParallel. (XXX: What about ComboCIDs?)

== Heavyweight Lock Management ==

Without changes to the lock manager, an undetected deadlock will occur if a worker backend tries to take a lock incompatible with one already held by the user backend. We could fix this by forbidding the user backend from holding any strong locks and allowing worker backends to take only weak locks, but that feels like an artificial restriction. It seems better to revise the heavyweight lock manager so that the user backend and its workers form a locking group whose locks are mutually non-conflicting.

== Function Labeling ==

Functions will need to be labeled as parallel-safe, or not. It would be nice if this marking were sufficiently general as to apply to other things we might want to parallelize in the future, not just parallel sort. Details to be worked out. If a function is labelled as parallel-safe, it mustn't do anything that isn't allowed while InParallel (see above).

== Parallel Sort ==

=== Planning ===

Decide whether the sort is expensive enough to be worth parallelizing. Or maybe, for CREATE INDEX, just let the user specify the desired level of parallelism, and forget about planning it.

=== Execution ===

Sort things, in parallel, using all the nifty infrastructure we've built up to this point.

=== Revamp of procost for btree operators ===

If the costs aren't accurate, we may make bad decisions about whether to parallelize. int4 comparisons are ~1000x cheaper than text comparisons, but right now the system doesn't know that.