Tag: pg84

Waiting for 8.4 – final post (?)

For quite some time I've been posting about new features in 8.4. First post was over a year ago, on 16th of February 2008.

Now, we just (yesterday) got nice surprise: beta is here:

(depesz@[local]:5840) 12:39:15 [depesz]
# select version();
                                                  version
-----------------------------------------------------------------------------------------------------------
 PostgreSQL 8.4beta1 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3), 32-bit
(1 row)

Since I don't expect any new features in beta and release candidate stages, let me put some short summary.

Continue reading Waiting for 8.4 – final post (?)

Waiting for 8.4 – no more -d in pg_dump!

Usually I write about new features in 8.4, but this time I'd like to write about feature that will be actually missing in 8.4. And thank God, it will be missing.

On Mon, 09 Mar 2009 11:22:47 -0400 Greg Sabino Mullane wrote mail to pgsql-hackers list with his patch that removes -d switch from pg_dump.

Later there was some discussion (20 mails) that extended the patch to remove also -D.

And now, today, Tom Lane committed:

Remove the -d and -D options of pg_dump and pg_dumpall.  The functionality
is still available, but you must now write the long equivalent --inserts
or --column-inserts.  This change is made to eliminate confusion with the
use of -d to specify a database name in most other Postgres client programs.
Original patch by Greg Mullane, modified per subsequent discussion.

This is great news. One less way a new user of pg (or one that doesn't read –help pages) can do himself harm, one less thing that is purely illogical.

Waiting for 8.4 – parallel restoration of dumps

On 2nd of February Andrew Dunstan committed his patch (with editing by Tom Lane) that:

Log Message:
-----------
Provide for parallel restoration from a custom format archive. Each data and
post-data step is run in a separate worker child (a thread on Windows, a child
process elsewhere) up to the concurrent number specified by the new pg_restore
command-line --multi-thread | -m switch.

Continue reading Waiting for 8.4 – parallel restoration of dumps

Waiting for 8.4 – column level privileges.

On 22nd of January, Tom Lane committed patch by Stephen Frost, which adds column level privileges:

Log Message:
-----------
Support column-level privileges, as required by SQL standard.
 
Stephen Frost, with help from KaiGai Kohei and others

Continue reading Waiting for 8.4 – column level privileges.

Waiting for 8.4 – window functions

A long overdue post about new functionality. At this moment it is no longer such new, as it was committed on 28th of December (yes, I know, I should have written it earlier, Sorry).

On this day Tom Lane committed patch by Hitoshi Harada which adds support for so called window functions:

Support window functions a la SQL:2008.
 
Hitoshi Harada, with some kibitzing from Heikki and Tom.

Continue reading Waiting for 8.4 – window functions

Waiting for 8.4 – pg_stat_statements

On 4th of January, Tom Lane committed patch by Takahiro Itagaki, which adds new contrib module – pg_stat_statements:

Log Message:
-----------
Add contrib/pg_stat_statements for server-wide tracking of statement execution
statistics.
 
Takahiro Itagaki

Continue reading Waiting for 8.4 – pg_stat_statements

Waiting for 8.4 – Default values for function arguments + integer in any base

On 4th of December Peter Eisentraut committed patch by Pavel Stehule (with Peters tweaks) which adds default values for function arguments:

Default values for function arguments
 
Pavel Stehule, with some tweaks by Peter Eisentraut

Continue reading Waiting for 8.4 – Default values for function arguments + integer in any base

Waiting for 8.4 – Visibility maps

Yeah. This one patch alone is worth upgrading to 8.4.

On 3rd of December Heikki Linnakangas committed his patch. Commit message:

Introduce visibility map. The visibility map is a bitmap with one bit per
heap page, where a set bit indicates that all tuples on the page are
visible to all transactions, and the page therefore doesn't need
vacuuming. It is stored in a new relation fork.
 
Lazy vacuum uses the visibility map to skip pages that don't need
vacuuming. Vacuum is also responsible for setting the bits in the map.
In the future, this can hopefully be used to implement index-only-scans,
but we can't currently guarantee that the visibility map is always 100%
up-to-date.
 
In addition to the visibility map, there's a new PD_ALL_VISIBLE flag on
each heap page, also indicating that all tuples on the page are visible to
all transactions. It's important that this flag is kept up-to-date. It
is also used to skip visibility tests in sequential scans, which gives a
small performance gain on seqscans.

Continue reading Waiting for 8.4 – Visibility maps