Re: Major features for 9.1

All,

Here's a list of the features which seem to me to be major enough to be
headliners for 9.1. Please mark which ones you think are major/not
major/not major and anything you think I've forgotten.

The tough part is going to be picking 5-6 items from the below.

* Synchronous Replication
Reason: obvious

* wCTE: Writeable Common Table Expressions
Reason: replace large amounts of app code with single queries.
Also, we may be the first DB to have this. Anyone know?

* Per-column collations
Reason: fully multilingual databases now possible.
This has been a TODO for a decade.

* SSI: Serializable Snapshot Isolation
True serializability without locking. Eliminate a lot of SELECT FOR
UPDATE code.
This might also be a PostgreSQL first.

* Unlogged Tables
Reason: allows using Postgres for not-valuable, high-performance data
like session tables instead of using a caching database

* SQL/MED with FILE_FDW
Reason: allows using PostgreSQL to query any kind of data source you can
roll a driver for. First one shipping reads CSV files, eliminating the
need to COPY them into the database in many cases.

* KNN-GiST: K-Nearest Neighbor Indexing
Permits indexed searches of "what's near X", greatly improving the
responsiveness of PostGIS applications and allowing new application
types to be built.

* Single-command cloning, new admin tools for replication
Not sure about this one, should probably be buried in text somewhere.

* PL/Python Overhaul
Not sure what went into this, can anyone give me details?

* SEPostgres
SE-Postgres has been integrated into PostgreSQL through generic security
hooks and a contrib module. Allows "military" level security/control
over database.

* Extensions
Optional PostgreSQL code, such as extra data types, GIS, languages, etc,
can now be packaged as pluggable extensions, greatly simplifying
installing and upgrading them. In addition, the PGXN network will
become an online repository of these extensions.

Ones I don't think are major features but are cool anyway:

* Valid-on-creation FKs
* Checkpoint Goggles
* Extensible ENUMs
* Triggers on Views
* New Trigram implementation (text is similar to ...)
* Reduced NUMERIC size

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

On 1 April 2011 20:21, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> All,
>
> Here's a list of the features which seem to me to be major enough to be
> headliners for 9.1.  Please mark which ones you think are major/not
> major/not major and anything you think I've forgotten.
>
> The tough part is going to be picking 5-6 items from the below.
>
> * Synchronous Replication
> Reason: obvious
>
> * wCTE: Writeable Common Table Expressions
> Reason: replace large amounts of app code with single queries.
> Also, we may be the first DB to have this.  Anyone know?
>
> * Per-column collations
> Reason: fully multilingual databases now possible.
> This has been a TODO for a decade.
>
> * SSI: Serializable Snapshot Isolation
> True serializability without locking.  Eliminate a lot of SELECT FOR
> UPDATE code.
> This might also be a PostgreSQL first.
>
> * Unlogged Tables
> Reason: allows using Postgres for not-valuable, high-performance data
> like session tables instead of using a caching database
>
> * SQL/MED with FILE_FDW
> Reason: allows using PostgreSQL to query any kind of data source you can
> roll a driver for.  First one shipping reads CSV files, eliminating the
> need to COPY them into the database in many cases.
>
> * KNN-GiST: K-Nearest Neighbor Indexing
> Permits indexed searches of "what's near X", greatly improving the
> responsiveness of PostGIS applications and allowing new application
> types to be built.
>
> * Single-command cloning, new admin tools for replication
> Not sure about this one, should probably be buried in text somewhere.
>
> * PL/Python Overhaul
> Not sure what went into this, can anyone give me details?
>
> * SEPostgres
> SE-Postgres has been integrated into PostgreSQL through generic security
> hooks and a contrib module.  Allows "military" level security/control
> over database.
>
> * Extensions
> Optional PostgreSQL code, such as extra data types, GIS, languages, etc,
> can now be packaged as pluggable extensions, greatly simplifying
> installing and upgrading them.  In addition, the PGXN network will
> become an online repository of these extensions.
>
> Ones I don't think are major features but are cool anyway:
>
> * Valid-on-creation FKs
> * Checkpoint Goggles
> * Extensible ENUMs
> * Triggers on Views
> * New Trigram implementation (text is similar to ...)
> * Reduced NUMERIC size

What about column data type alterations for populated tables which
don't require rewrites if they're binary-coercible?

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Fri, 2011-04-01 at 12:21 -0700, Josh Berkus wrote:
> All,
>
> Here's a list of the features which seem to me to be major enough to be
> headliners for 9.1. Please mark which ones you think are major/not
> major/not major and anything you think I've forgotten.
>
> The tough part is going to be picking 5-6 items from the below.
>
> * Synchronous Replication
> Reason: obvious

+1

>
> * wCTE: Writeable Common Table Expressions
> Reason: replace large amounts of app code with single queries.
> Also, we may be the first DB to have this. Anyone know?
>
> * Per-column collations
> Reason: fully multilingual databases now possible.
> This has been a TODO for a decade.
>
> * SSI: Serializable Snapshot Isolation
> True serializability without locking. Eliminate a lot of SELECT FOR
> UPDATE code.
> This might also be a PostgreSQL first.

-1 (it is a great feature but doesn't mean anything to the wider
"press")

>
> * Unlogged Tables
> Reason: allows using Postgres for not-valuable, high-performance data
> like session tables instead of using a caching database

+1

>
> * SQL/MED with FILE_FDW
> Reason: allows using PostgreSQL to query any kind of data source you can
> roll a driver for. First one shipping reads CSV files, eliminating the
> need to COPY them into the database in many cases.
>

+1

> * KNN-GiST: K-Nearest Neighbor Indexing
> Permits indexed searches of "what's near X", greatly improving the
> responsiveness of PostGIS applications and allowing new application
> types to be built.

~ +/- 1

>
> * Single-command cloning, new admin tools for replication
> Not sure about this one, should probably be buried in text somewhere.
>

-1

> * PL/Python Overhaul
> Not sure what went into this, can anyone give me details?
>
-1

> * SEPostgres
> SE-Postgres has been integrated into PostgreSQL through generic security
> hooks and a contrib module. Allows "military" level security/control
> over database.
>

+1

> * Extensions
> Optional PostgreSQL code, such as extra data types, GIS, languages, etc,
> can now be packaged as pluggable extensions, greatly simplifying
> installing and upgrading them. In addition, the PGXN network will
> become an online repository of these extensions.
>

+1

JD
--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering
http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt

Hello

2011/4/1 Josh Berkus <josh(at)agliodbs(dot)com>:
> All,
>
> Here's a list of the features which seem to me to be major enough to be
> headliners for 9.1.  Please mark which ones you think are major/not
> major/not major and anything you think I've forgotten.
>
> The tough part is going to be picking 5-6 items from the below.
>
> * Synchronous Replication
> Reason: obvious
>
> * wCTE: Writeable Common Table Expressions
> Reason: replace large amounts of app code with single queries.
> Also, we may be the first DB to have this.  Anyone know?
>

+1

> * Per-column collations
> Reason: fully multilingual databases now possible.
> This has been a TODO for a decade.
>

+1

> * SSI: Serializable Snapshot Isolation
> True serializability without locking.  Eliminate a lot of SELECT FOR
> UPDATE code.
> This might also be a PostgreSQL first.
>

+1

> * Unlogged Tables
> Reason: allows using Postgres for not-valuable, high-performance data
> like session tables instead of using a caching database
>

+1

> * SQL/MED with FILE_FDW
> Reason: allows using PostgreSQL to query any kind of data source you can
> roll a driver for.  First one shipping reads CSV files, eliminating the
> need to COPY them into the database in many cases.
>

-1

> * KNN-GiST: K-Nearest Neighbor Indexing
> Permits indexed searches of "what's near X", greatly improving the
> responsiveness of PostGIS applications and allowing new application
> types to be built.
>

+1
> * Single-command cloning, new admin tools for replication
> Not sure about this one, should probably be buried in text somewhere.
>

-1
> * PL/Python Overhaul
> Not sure what went into this, can anyone give me details?
>

-1

> * SEPostgres
> SE-Postgres has been integrated into PostgreSQL through generic security
> hooks and a contrib module.  Allows "military" level security/control
> over database.

-1

>
> * Extensions
> Optional PostgreSQL code, such as extra data types, GIS, languages, etc,
> can now be packaged as pluggable extensions, greatly simplifying
> installing and upgrading them.  In addition, the PGXN network will
> become an online repository of these extensions.
>

-1

I am thinking so 9.1 is little bit blurred - The most cool feature
highly depends on user group - PostGIS (KNN-GiST), ETL (unlogged
tables), in europe we like collations, developers will like wCTE, and
Java and Hibernate people will like SSI. A border is too wide. I like
SQL/MED but I am thinking, so this needs more time and as minimim is
real support for other SQL servers - this feature isn't completed now,
SEPostgres needs lot of love from people who work on distributions. I
don't know anybody, who can use this feature.

> Ones I don't think are major features but are cool anyway:
>
> * Valid-on-creation FKs
> * Checkpoint Goggles
> * Extensible ENUMs
> * Triggers on Views

-1

> * New Trigram implementation (text is similar to ...)

it is good marketing feature :) - same is functional dependency for
GROUP BY clause.

> * Reduced NUMERIC size

-1

I like all features - but not all can be mayor :)

Pavel

>
> --
> Josh Berkus
> PostgreSQL Experts Inc.
> http://pgexperts.com
>
> --
> Sent via pgsql-advocacy mailing list (pgsql-advocacy(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-advocacy
>

Le 01/04/2011 21:21, Josh Berkus a écrit :
> All,
>
> Here's a list of the features which seem to me to be major enough to be
> headliners for 9.1. Please mark which ones you think are major/not
> major/not major and anything you think I've forgotten.
>
> The tough part is going to be picking 5-6 items from the below.
>
> * Synchronous Replication
> Reason: obvious
>

+1
Not my personal favorite feature in 9.1, but it's one that people will
notice.

> * wCTE: Writeable Common Table Expressions
> Reason: replace large amounts of app code with single queries.
> Also, we may be the first DB to have this. Anyone know?
>
> * Per-column collations
> Reason: fully multilingual databases now possible.
> This has been a TODO for a decade.
>

+1

> * SSI: Serializable Snapshot Isolation
> True serializability without locking. Eliminate a lot of SELECT FOR
> UPDATE code.
> This might also be a PostgreSQL first.
>
> * Unlogged Tables
> Reason: allows using Postgres for not-valuable, high-performance data
> like session tables instead of using a caching database
>

+1

> * SQL/MED with FILE_FDW
> Reason: allows using PostgreSQL to query any kind of data source you can
> roll a driver for. First one shipping reads CSV files, eliminating the
> need to COPY them into the database in many cases.
>

+1
One of my two personal favorites features in 9.1.

> * KNN-GiST: K-Nearest Neighbor Indexing
> Permits indexed searches of "what's near X", greatly improving the
> responsiveness of PostGIS applications and allowing new application
> types to be built.
>
> * Single-command cloning, new admin tools for replication
> Not sure about this one, should probably be buried in text somewhere.
>

+1 (but I would better say "Better administration and monitoring
features for replication")

> * PL/Python Overhaul
> Not sure what went into this, can anyone give me details?
>
> * SEPostgres
> SE-Postgres has been integrated into PostgreSQL through generic security
> hooks and a contrib module. Allows "military" level security/control
> over database.
>
> * Extensions
> Optional PostgreSQL code, such as extra data types, GIS, languages, etc,
> can now be packaged as pluggable extensions, greatly simplifying
> installing and upgrading them. In addition, the PGXN network will
> become an online repository of these extensions.
>

+1
The other one of my two personal favorites features in 9.1.

> Ones I don't think are major features but are cool anyway:
>
> * Valid-on-creation FKs
> * Checkpoint Goggles
> * Extensible ENUMs
> * Triggers on Views
> * New Trigram implementation (text is similar to ...)
> * Reduced NUMERIC size
>

--
Guillaume
http://www.postgresql.fr
http://dalibo.com

Josh Berkus <josh(at)agliodbs(dot)com> wrote:

> * Synchronous Replication
> Reason: obvious

Gotta mention this, based on constantly expressed interest.

+1

> * wCTE: Writeable Common Table Expressions
> Reason: replace large amounts of app code with single queries.
> Also, we may be the first DB to have this. Anyone know?

This is very cool, but I don't know how many people know enough
about CTEs to be impressed.

> * Per-column collations
> Reason: fully multilingual databases now possible.
> This has been a TODO for a decade.

Not big for me, but I'll bet in certain countries or application
types it is huge.

> * SSI: Serializable Snapshot Isolation
> True serializability without locking. Eliminate a lot of SELECT
> FOR UPDATE code.
> This might also be a PostgreSQL first.

Obviously *I* think it's big. Besides the on-list posts, I've
gotten quite a few off-list emails and comments at conferences which
make me think there are a lot of others interested. Notice the
aggressive testing it got once it hit alpha. I'm pretty sure I'd
have heard about it or run across it in web searches if anybody else
had beat us to this. (I would say that "without blocking" would be
more technically accurate than "without locking".)

+1

> * Unlogged Tables
> Reason: allows using Postgres for not-valuable, high-performance
> data like session tables instead of using a caching database

This will be very useful for our shop, but like CTEs, I don't know
how many people in the wider audience will be as impressed by this
as the other items.

> * SQL/MED with FILE_FDW
> Reason: allows using PostgreSQL to query any kind of data source
> you can roll a driver for. First one shipping reads CSV files,
> eliminating the need to COPY them into the database in many cases.

I have no idea how big the audience is for this one.

> * KNN-GiST: K-Nearest Neighbor Indexing
> Permits indexed searches of "what's near X", greatly improving the
> responsiveness of PostGIS applications and allowing new
> application types to be built.

This is very cool, although I don't think I'll have any use for it.
The audience may be smaller than for other features.

> * Single-command cloning, new admin tools for replication
> Not sure about this one, should probably be buried in text
> somewhere.

Agree on including in text but not major feature point.

> * PL/Python Overhaul
> Not sure what went into this, can anyone give me details?

As valuable as this is, an overhaul doesn't sound like a major
feature, on the face of it.

-1

> * SEPostgres
> SE-Postgres has been integrated into PostgreSQL through generic
> security hooks and a contrib module. Allows "military" level
> security/control over database.

Clearly there is a lot of interest in certain quarters. My concern
on pushing it as a major feature is that, given the nature of the
community which needs this, I suspect that those who really care
already know it's coming in 9.1, and those who don't already know
won't care so much. (I could be wrong about that, though.)

> * Extensions
> Optional PostgreSQL code, such as extra data types, GIS,
> languages, etc, can now be packaged as pluggable extensions,
> greatly simplifying installing and upgrading them. In addition,
> the PGXN network will become an online repository of these
> extensions.

That's big.

+1

-Kevin

Hi all,

I realize that by chance my choices are exactly the same as Guillaume's list !
So no need to repeat ;-) . Just count +2 !
And I fully agree with his comments too.

Regards.
Philippe Beaudoin.

Guillaume Lelarge a écrit :
> Le 01/04/2011 21:21, Josh Berkus a écrit :
>
>> All,
>>
>> Here's a list of the features which seem to me to be major enough to be
>> headliners for 9.1. Please mark which ones you think are major/not
>> major/not major and anything you think I've forgotten.
>>
>> The tough part is going to be picking 5-6 items from the below.
>>
>> * Synchronous Replication
>> Reason: obvious
>>
>>
>
> +1
> Not my personal favorite feature in 9.1, but it's one that people will
> notice.
>
>
>> * wCTE: Writeable Common Table Expressions
>> Reason: replace large amounts of app code with single queries.
>> Also, we may be the first DB to have this. Anyone know?
>>
>> * Per-column collations
>> Reason: fully multilingual databases now possible.
>> This has been a TODO for a decade.
>>
>>
>
> +1
>
>
>> * SSI: Serializable Snapshot Isolation
>> True serializability without locking. Eliminate a lot of SELECT FOR
>> UPDATE code.
>> This might also be a PostgreSQL first.
>>
>> * Unlogged Tables
>> Reason: allows using Postgres for not-valuable, high-performance data
>> like session tables instead of using a caching database
>>
>>
>
> +1
>
>
>> * SQL/MED with FILE_FDW
>> Reason: allows using PostgreSQL to query any kind of data source you can
>> roll a driver for. First one shipping reads CSV files, eliminating the
>> need to COPY them into the database in many cases.
>>
>>
>
> +1
> One of my two personal favorites features in 9.1.
>
>
>> * KNN-GiST: K-Nearest Neighbor Indexing
>> Permits indexed searches of "what's near X", greatly improving the
>> responsiveness of PostGIS applications and allowing new application
>> types to be built.
>>
>> * Single-command cloning, new admin tools for replication
>> Not sure about this one, should probably be buried in text somewhere.
>>
>>
>
> +1 (but I would better say "Better administration and monitoring
> features for replication")
>
>
>> * PL/Python Overhaul
>> Not sure what went into this, can anyone give me details?
>>
>> * SEPostgres
>> SE-Postgres has been integrated into PostgreSQL through generic security
>> hooks and a contrib module. Allows "military" level security/control
>> over database.
>>
>> * Extensions
>> Optional PostgreSQL code, such as extra data types, GIS, languages, etc,
>> can now be packaged as pluggable extensions, greatly simplifying
>> installing and upgrading them. In addition, the PGXN network will
>> become an online repository of these extensions.
>>
>>
>
> +1
> The other one of my two personal favorites features in 9.1.
>
>
>> Ones I don't think are major features but are cool anyway:
>>
>> * Valid-on-creation FKs
>> * Checkpoint Goggles
>> * Extensible ENUMs
>> * Triggers on Views
>> * New Trigram implementation (text is similar to ...)
>> * Reduced NUMERIC size
>>
>>
>
>
>

Here's my thoughts...

> Here's a list of the features which seem to me to be major enough to be
> headliners for 9.1. Please mark which ones you think are major/not
> major/not major and anything you think I've forgotten.
>
> ... picking 5-6 items ...

> Synchronous Replication

+1

it's the flavour of the day

> * wCTE: Writeable Common Table Expressions

+1

I'm finding myself using a lot of Common Table Expressions it's more intuitive
than the more traditional BEGIN .. COMMIT paradigm especially for
programmers/developers

> * Per-column collations

-1

>
> * SSI: Serializable Snapshot Isolation
> True serializability without locking.

-1

You have to explain this otherwise there's no point in promoting this

> * Unlogged Tables
> Reason: allows using Postgres for not-valuable, high-performance data
> like session tables instead of using a caching database

+1

This is a sleeper. Drop the apology that it's for 'not-valuable' data. I can
see a lot of places that can allow pg to enter the big-data / cassandra /
hbase world

> * SQL/MED with FILE_FDW

+1

> * KNN-GiST: K-Nearest Neighbor Indexing
> Permits indexed searches of "what's near X", greatly improving the
> responsiveness of PostGIS applications and allowing new application
> types to be built.

-1

> * Single-command cloning, new admin tools for replication
> Not sure about this one, should probably be buried in text somewhere.

-1

Should be massaged as part of the continuing evolution of replication support,
the first point.

> * PL/Python Overhaul

-1

need more details to vote on it

> SEPostgres

-1

requires a user-case i.e. show how a past high profile exploit could have been
stopped with this mechanism in place.

> Extensions

+1

I suggest a user-case explanation of how would it be used

On Fri, Apr 1, 2011 at 8:21 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> All,
>
> Here's a list of the features which seem to me to be major enough to be
> headliners for 9.1.  Please mark which ones you think are major/not
> major/not major and anything you think I've forgotten.
>
> The tough part is going to be picking 5-6 items from the below.
>
> * Synchronous Replication
> Reason: obvious
>
> * wCTE: Writeable Common Table Expressions
> Reason: replace large amounts of app code with single queries.
> Also, we may be the first DB to have this.  Anyone know?
>
> * Per-column collations
> Reason: fully multilingual databases now possible.
> This has been a TODO for a decade.
>
> * SSI: Serializable Snapshot Isolation
> True serializability without locking.  Eliminate a lot of SELECT FOR
> UPDATE code.
> This might also be a PostgreSQL first.

Perhaps we can outline Major Features and Innovations separately. This
release is notable for the number of genuinely new ideas implemented,
so that's worth making something of even if the advanced features
themselves need a little more explanation. Or Perhaps have
"Innovations" as a major feature and then a comma list of the names of
them.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

> Perhaps we can outline Major Features and Innovations separately. This
> release is notable for the number of genuinely new ideas implemented,
> so that's worth making something of even if the advanced features
> themselves need a little more explanation. Or Perhaps have
> "Innovations" as a major feature and then a comma list of the names of
> them.

Yeah, that sounds like the way to go.

So for Innovations, we'd have SSI, SE/Postgres, KNN-GiST, and wCTE, no?
Or does someone else have wCTEs? I vaguely remember something about
SQL Server ...

There's also another obvious grouping: Extensibility. This would
include both Extensions and SQL/MED.

So we could have:

Features
Sync Rep
Per-col collation
Unlogged tables

Innovations
SSI
KNN-GiST
SE/Postgres
wCTE

Extensibility
Extensions
SQL/MED

I like that, it means we can list everything but without having a long
laundry list which nobody will read.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

On Sat, Apr 2, 2011 at 11:32 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>
>> Perhaps we can outline Major Features and Innovations separately. This
>> release is notable for the number of genuinely new ideas implemented,
>> so that's worth making something of even if the advanced features
>> themselves need a little more explanation. Or Perhaps have
>> "Innovations" as a major feature and then a comma list of the names of
>> them.
>
> Yeah, that sounds like the way to go.
>
> So for Innovations, we'd have SSI, SE/Postgres, KNN-GiST, and wCTE, no?
>  Or does someone else have wCTEs?  I vaguely remember something about
> SQL Server ...

wCTEs are definitely in SQLServer 2008

I would add Sync Rep also, since the transaction-controlled part is
new and original.

> There's also another obvious grouping: Extensibility.  This would
> include both Extensions and SQL/MED.
>
> So we could have:
>
> Features
>        Sync Rep
>        Per-col collation
>        Unlogged tables
>
> Innovations
>        SSI
>        KNN-GiST
>        SE/Postgres
>        wCTE
>
> Extensibility
>        Extensions
>        SQL/MED
>
> I like that, it means we can list everything but without having a long
> laundry list which nobody will read.

Key Features
Innovations
Extensions

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

On lör, 2011-04-02 at 15:32 -0700, Josh Berkus wrote:
> Or does someone else have wCTEs? I vaguely remember something about
> SQL Server ...

Since they're in the SQL:2011 standards draft, they must have been
implemented somewhere before.

On lör, 2011-04-02 at 15:32 -0700, Josh Berkus wrote:
> Innovations
> SSI
> KNN-GiST
> SE/Postgres
> wCTE

I assume you mean by "innovation" that these are things where PostgreSQL
was the first DBMS to implement them. The risk with that is, unless you
do very careful research, someone might debunk each of these within 24
hours after the release, making the whole thing look foolish.

Moreover, the fact that something might have been innovated doesn't
explain how it helps the user.

* Kevin Grittner:

>> * SSI: Serializable Snapshot Isolation
>> True serializability without locking. Eliminate a lot of SELECT
>> FOR UPDATE code.
>> This might also be a PostgreSQL first.
>
> Obviously *I* think it's big. Besides the on-list posts, I've
> gotten quite a few off-list emails and comments at conferences which
> make me think there are a lot of others interested. Notice the
> aggressive testing it got once it hit alpha. I'm pretty sure I'd
> have heard about it or run across it in web searches if anybody else
> had beat us to this. (I would say that "without blocking" would be
> more technically accurate than "without locking".)
>
> +1

Does SSI address the UPSERT race? If yes, it's going to help a lot of
people indeed.

--
Florian Weimer <fweimer(at)bfk(dot)de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

>
> * Synchronous Replication
> Reason: obvious
>

+1

> * wCTE: Writeable Common Table Expressions
> Reason: replace large amounts of app code with single queries.
> Also, we may be the first DB to have this.  Anyone know?
>

-/+1

> * Per-column collations
> Reason: fully multilingual databases now possible.
> This has been a TODO for a decade.
>
> * SSI: Serializable Snapshot Isolation
> True serializability without locking.  Eliminate a lot of SELECT FOR
> UPDATE code.
> This might also be a PostgreSQL first.
>

+1

> * Unlogged Tables
> Reason: allows using Postgres for not-valuable, high-performance data
> like session tables instead of using a caching database
>

+1

> * SQL/MED with FILE_FDW
> Reason: allows using PostgreSQL to query any kind of data source you can
> roll a driver for.  First one shipping reads CSV files, eliminating the
> need to COPY them into the database in many cases.
>

+1

> * KNN-GiST: K-Nearest Neighbor Indexing
> Permits indexed searches of "what's near X", greatly improving the
> responsiveness of PostGIS applications and allowing new application
> types to be built.
>
> * Single-command cloning, new admin tools for replication
> Not sure about this one, should probably be buried in text somewhere.
>

+1

> * PL/Python Overhaul
> Not sure what went into this, can anyone give me details?
>
> * SEPostgres
> SE-Postgres has been integrated into PostgreSQL through generic security
> hooks and a contrib module.  Allows "military" level security/control
> over database.
>
> * Extensions
> Optional PostgreSQL code, such as extra data types, GIS, languages, etc,
> can now be packaged as pluggable extensions, greatly simplifying
> installing and upgrading them.  In addition, the PGXN network will
> become an online repository of these extensions.
>
> Ones I don't think are major features but are cool anyway:
>
> * Valid-on-creation FKs
> * Checkpoint Goggles
> * Extensible ENUMs

+1

> * Triggers on Views
> * New Trigram implementation (text is similar to ...)
> * Reduced NUMERIC size

+1

--
--
              Emanuel Calvo
              Helpame.com

> I assume you mean by "innovation" that these are things where
> PostgreSQL
> was the first DBMS to implement them. The risk with that is, unless
> you
> do very careful research, someone might debunk each of these within 24
> hours after the release, making the whole thing look foolish.

Well, we can hedge a bit. But, better, can someone (preferably several someones) on this list volunteer to do research? Anyone?

>
> Moreover, the fact that something might have been innovated doesn't
> explain how it helps the user.

Truthfully, for a press release, it doesn't matter. Many reporters/bloggers will happily quote that we're the first database with SSI without having a clue what it means. In general, most reporters who cover databases don't really know know (or care) much about databases regardless (or "NoSQL" wouldn't have the press it does).

From a PR perspective, the important thing to get across is that the PostgreSQL project is innovating, implementing new database tech before anyone else. This is critically important during a period where SQL-RDBMSes are being portrayed as "old grandfathers" in a press more enchanted with "the new hotness" of recently invented DBMSes.

Now, for our users and for serious database geeks, we *do* need an elevator-pitch explanation of several features which tells them why they should care. Several features in particular are not immediately obvious:

* SSI
* wCTE
* KNN-GiST
* SE-Postgres
* Transaction-controlled Synch Rep

I would like to have volunteers from the advocacy list commit to taking on one of each of these features. For each one we need:

a) a two-line explanation of what the feature is and why it's valuable (for the release notes, etc.)
b) a wiki page with a more detailed explaination and examples oriented towards the beginning-to-intermediate PostgreSQL user.

Volunteers?

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
San Francisco

I'm starting research on 'innovation' in database technologies. To be sure
I'm on the right track, this thread is about serializable architecture, or,
transaction locking.
Furthermore, upserts are an umbrella term for 'insert' and 'update'.
So far so good, but when it comes to SSI I am not finding any explanations
for this acronym.

Searching for the predicate of a real database: ...
Andrew Lardinois

On Sun, Apr 3, 2011 at 11:18 AM, Joshua Berkus <josh(at)agliodbs(dot)com> wrote:

>
>
> > I assume you mean by "innovation" that these are things where
> > PostgreSQL
> > was the first DBMS to implement them. The risk with that is, unless
> > you
> > do very careful research, someone might debunk each of these within 24
> > hours after the release, making the whole thing look foolish.
>
> Well, we can hedge a bit. But, better, can someone (preferably several
> someones) on this list volunteer to do research? Anyone?
>
> >
> > Moreover, the fact that something might have been innovated doesn't
> > explain how it helps the user.
>
> Truthfully, for a press release, it doesn't matter. Many
> reporters/bloggers will happily quote that we're the first database with SSI
> without having a clue what it means. In general, most reporters who cover
> databases don't really know know (or care) much about databases regardless
> (or "NoSQL" wouldn't have the press it does).
>
> From a PR perspective, the important thing to get across is that the
> PostgreSQL project is innovating, implementing new database tech before
> anyone else. This is critically important during a period where SQL-RDBMSes
> are being portrayed as "old grandfathers" in a press more enchanted with
> "the new hotness" of recently invented DBMSes.
>
> Now, for our users and for serious database geeks, we *do* need an
> elevator-pitch explanation of several features which tells them why they
> should care. Several features in particular are not immediately obvious:
>
> * SSI
> * wCTE
> * KNN-GiST
> * SE-Postgres
> * Transaction-controlled Synch Rep
>
> I would like to have volunteers from the advocacy list commit to taking on
> one of each of these features. For each one we need:
>
> a) a two-line explanation of what the feature is and why it's valuable (for
> the release notes, etc.)
> b) a wiki page with a more detailed explaination and examples oriented
> towards the beginning-to-intermediate PostgreSQL user.
>
> Volunteers?
>
>
> --
> Josh Berkus
> PostgreSQL Experts Inc.
> http://pgexperts.com
> San Francisco
>
> --
> Sent via pgsql-advocacy mailing list (pgsql-advocacy(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-advocacy
>

El dom, 03-04-2011 a las 09:32 +0100, Simon Riggs escribió:
> On Sat, Apr 2, 2011 at 11:32 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> >

>
> Key Features
> Innovations
> Extensions
>
+1
--
Saludos,
Gilberto Castillo
Edificio Beijing. Miramar Trade Center. Etecsa.
Miramar, La Habana.Cuba.

El dom, 03-04-2011 a las 12:43 +0300, Peter Eisentraut escribió:
> On lör, 2011-04-02 at 15:32 -0700, Josh Berkus wrote:
> > Innovations
> > SSI
> > KNN-GiST
> > SE/Postgres
> > wCTE
>
> I assume you mean by "innovation" that these are things where PostgreSQL
> was the first DBMS to implement them. The risk with that is, unless you
> do very careful research, someone might debunk each of these within 24
> hours after the release, making the whole thing look foolish.
>
> Moreover, the fact that something might have been innovated doesn't
> explain how it helps the user.
>

Placing a possible example was used for each.

--
Saludos,
Gilberto Castillo
Edificio Beijing. Miramar Trade Center. Etecsa.
Miramar, La Habana.Cuba.

Kevin Grittner wrote:

>> * wCTE: Writeable Common Table Expressions
>> Reason: replace large amounts of app code with single queries.
>> Also, we may be the first DB to have this. Anyone know?
>
> This is very cool, but I don't know how many people know enough
> about CTEs to be impressed.

But those of us who do, are *itching* to use them in production applications
instead of having to pull everything into application code (or pl/*
functions) just to push into another query ;-)


>> * SQL/MED with FILE_FDW
>> Reason: allows using PostgreSQL to query any kind of data source
>> you can roll a driver for. First one shipping reads CSV files,
>> eliminating the need to COPY them into the database in many cases.
>
> I have no idea how big the audience is for this one.

I *hope* this will really grow though, through adoption of extensions, and
PGXN...

Man 9.1 is packed with good stuff ;-)

a.

Joshua Berkus <josh(at)agliodbs(dot)com> wrote:

> I would like to have volunteers from the advocacy list commit to
> taking on one of each of these features. For each one we need:

> b) a wiki page with a more detailed explaination and examples
> oriented towards the beginning-to-intermediate PostgreSQL user.

I've gotten a start on a wiki page with one example so far:

http://wiki.postgresql.org/wiki/SSI

Does this general format look OK for showing the SSI examples?

Is it at the desired technical level?

-Kevin

On fre, 2011-04-01 at 12:21 -0700, Josh Berkus wrote:
> Here's a list of the features which seem to me to be major enough to
> be
> headliners for 9.1. Please mark which ones you think are major/not
> major/not major and anything you think I've forgotten.

I guess it's not really a big feature, but the functional dependency
tracking feature that allows trimming down GROUP BY lists will
significantly cut down on questions and "bug reports" from especially
MySQL converts.

On Wed, Apr 6, 2011 at 19:10, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On fre, 2011-04-01 at 12:21 -0700, Josh Berkus wrote:
>> Here's a list of the features which seem to me to be major enough to
>> be
>> headliners for 9.1.  Please mark which ones you think are major/not
>> major/not major and anything you think I've forgotten.
>
> I guess it's not really a big feature, but the functional dependency
> tracking feature that allows trimming down GROUP BY lists will
> significantly cut down on questions and "bug reports" from especially
> MySQL converts.

Are you sure? Many of the cases I've come across aren't covered by it,
because they're not actually functional dependencies... They're just
using the "give me whatever row you can think of feature" in mysql. So
while this certainly helps, I'm ont sure it will make a significant
cut in the number of questions...

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On ons, 2011-04-06 at 19:13 +0200, Magnus Hagander wrote:
> On Wed, Apr 6, 2011 at 19:10, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> > On fre, 2011-04-01 at 12:21 -0700, Josh Berkus wrote:
> >> Here's a list of the features which seem to me to be major enough to
> >> be
> >> headliners for 9.1. Please mark which ones you think are major/not
> >> major/not major and anything you think I've forgotten.
> >
> > I guess it's not really a big feature, but the functional dependency
> > tracking feature that allows trimming down GROUP BY lists will
> > significantly cut down on questions and "bug reports" from especially
> > MySQL converts.
>
> Are you sure? Many of the cases I've come across aren't covered by it,
> because they're not actually functional dependencies... They're just
> using the "give me whatever row you can think of feature" in mysql. So
> while this certainly helps, I'm ont sure it will make a significant
> cut in the number of questions...

Yes, many cases will still not work, but many will.

On Sun, Apr 03, 2011 at 01:18:35PM -0500, Josh Berkus wrote:
>
>
> > I assume you mean by "innovation" that these are things where
> > PostgreSQL
> > was the first DBMS to implement them. The risk with that is, unless
> > you
> > do very careful research, someone might debunk each of these within 24
> > hours after the release, making the whole thing look foolish.
>
> Well, we can hedge a bit. But, better, can someone (preferably several someones) on this list volunteer to do research? Anyone?
>
> >
> > Moreover, the fact that something might have been innovated doesn't
> > explain how it helps the user.
>
> Truthfully, for a press release, it doesn't matter. Many reporters/bloggers will happily quote that we're the first database with SSI without having a clue what it means. In general, most reporters who cover databases don't really know know (or care) much about databases regardless (or "NoSQL" wouldn't have the press it does).
>
> >From a PR perspective, the important thing to get across is that the PostgreSQL project is innovating, implementing new database tech before anyone else. This is critically important during a period where SQL-RDBMSes are being portrayed as "old grandfathers" in a press more enchanted with "the new hotness" of recently invented DBMSes.
>
> Now, for our users and for serious database geeks, we *do* need an elevator-pitch explanation of several features which tells them why they should care. Several features in particular are not immediately obvious:
>
> * SSI
> * wCTE
> * KNN-GiST
> * SE-Postgres
> * Transaction-controlled Synch Rep
>
> I would like to have volunteers from the advocacy list commit to taking on one of each of these features. For each one we need:
>
> a) a two-line explanation of what the feature is and why it's valuable (for the release notes, etc.)
> b) a wiki page with a more detailed explaination and examples oriented towards the beginning-to-intermediate PostgreSQL user.

I'll take a whack at wCTE :)

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Sun, Apr 03, 2011 at 12:38:02PM +0300, Peter Eisentraut wrote:
> On lör, 2011-04-02 at 15:32 -0700, Josh Berkus wrote:
> > Or does someone else have wCTEs? I vaguely remember something
> > about SQL Server ...
>
> Since they're in the SQL:2011 standards draft, they must have been
> implemented somewhere before.

What's in the SQL:2011 standards draft is a long way behind even our
current wCTE implementation[1], and it corresponds to something in DB2.

Cheers,
David.

[1] I have Evil Plans™ for further expansion.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Sun, Apr 03, 2011 at 09:32:27AM +0100, Simon Riggs wrote:
> On Sat, Apr 2, 2011 at 11:32 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> >
> >> Perhaps we can outline Major Features and Innovations separately.
> >> This release is notable for the number of genuinely new ideas
> >> implemented, so that's worth making something of even if the
> >> advanced features themselves need a little more explanation. Or
> >> Perhaps have "Innovations" as a major feature and then a comma
> >> list of the names of them.
> >
> > Yeah, that sounds like the way to go.
> >
> > So for Innovations, we'd have SSI, SE/Postgres, KNN-GiST, and
> > wCTE, no?  Or does someone else have wCTEs?  I vaguely remember
> > something about SQL Server ...
>
> wCTEs are definitely in SQLServer 2008

I haven't found them there (or anywhere else to date). Got a
reference I can check?

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Sat, Apr 02, 2011 at 10:39:51AM -0700, Robert Bernier wrote:
> > * wCTE: Writeable Common Table Expressions
>
> +1
>
> I'm finding myself using a lot of Common Table Expressions it's more intuitive
> than the more traditional BEGIN .. COMMIT paradigm especially for
> programmers/developers

Are you already using the data-changing part? :)

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

All,

> Yeah, that sounds like the way to go.
>
> So for Innovations, we'd have SSI, SE/Postgres, KNN-GiST, and wCTE,
> no?
> Or does someone else have wCTEs? I vaguely remember something about
> SQL Server ...

So, the research so far seems to indicate that:

SSI: PostgreSQL first
KNN-GiST: PostgreSQL first, but just barely: SQL Server will have this in November release.
wCTE: our "full implementation" is the first, version is SQL standard is much more limited. How to word this though?

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
San Francisco

On lör, 2011-04-09 at 12:39 -0500, Joshua Berkus wrote:
> wCTE: our "full implementation" is the first, version is SQL standard
> is much more limited. How to word this though?

"much more limited" is fuzzy and unsubstantiated. Maybe something like
a "powerful and flexible implementation of this concept".

On ons, 2011-04-06 at 17:41 -0700, David Fetter wrote:
> What's in the SQL:2011 standards draft is a long way behind even our
> current wCTE implementation[1], and it corresponds to something in
> DB2.

Could you give an example of that?

On Sat, 9 Apr 2011, Joshua Berkus wrote:

> All,
>
>> Yeah, that sounds like the way to go.
>>
>> So for Innovations, we'd have SSI, SE/Postgres, KNN-GiST, and wCTE,
>> no?
>> Or does someone else have wCTEs? I vaguely remember something about
>> SQL Server ...
>
> So, the research so far seems to indicate that:
>
> SSI: PostgreSQL first
> KNN-GiST: PostgreSQL first, but just barely: SQL Server will have this in November release.

their solution is slower than custom 2008 based solution and has very limited
(I see only spatial datatype).

> wCTE: our "full implementation" is the first, version is SQL standard is much more limited. How to word this though?
>
>

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

On 04/03/2011 02:18 PM, Joshua Berkus wrote:
> * Transaction-controlled Synch Rep
> I would like to have volunteers from the advocacy list commit to taking on one of each of these features. For each one we need:
>
> a) a two-line explanation of what the feature is and why it's valuable (for the release notes, etc.)
> b) a wiki page with a more detailed explaination and examples oriented towards the beginning-to-intermediate PostgreSQL user.
>

We already have http://wiki.postgresql.org/wiki/Synchronous_replication
for sync rep, and I just started changing that around so that it
reflects the code committed into 9.1. I got my first set of questions
today suggesting our internal work on documenting this from the ground
up is moving along. Over the next month we'll have at least two people
chugging away at making that targeted more toward beginners (or split
into something that is).

I've been doing the elevator pitch for sync rep for a while now; here's
a first draft description for the release notes:

Transaction-controlled Synchronous Replication: When replicating to
multiple nodes, customize every database transaction for its individual
speed and durability needs. Options range from only committing to
memory on the master up to the new synchronous standby mode, where data
must be stored on multiple servers to be considered safe.

The fact that several of the modes alluded to there were already
available on a per-transaction basis isn't new, but I think it's worth
being explicit about anyway because it's not really appreciated the way
it should be. Combine this with a pitch for unlogged tables and there's
an interesting angle to complete with NoSQL...wait, I'm feeling some
more ad copy:

PostgreSQL 9.1 lets you pick exactly the level of commit guarantee your
data requires. Whether you want unlogged tables optimized only for
speed, or you need durable synchronous replication to multiple servers,
you're covered--all in one database.

Need to take a shower to wash the stench of marketing off now.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us

Greg,

> Over the next month we'll have at least two people
> chugging away at making that targeted more toward beginners (or split
> into something that is).

Might I suggest something in the format of the Binary Replication Tutorial I started on the wiki? I have plans to update that for 9.1 and finish it, and of course would welcome expansion/help.

One thing I'm unexpectedly pleased about is that, after 1000 e-mails of design arguments, the Synch Rep we ended up with is simple and easy to understand. I was able to explain it in a LWN article in 200 words. How unlike this project. ;-)

I'm working with GoGrid on getting some PostgreSQL 9.1 Replication images up for use of all GoGrid users, as well. Someone else could replicate my work at Rackspace and Amazon.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
San Francisco

On Fri, Apr 1, 2011 at 8:21 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:

> * SQL/MED with FILE_FDW
> Reason: allows using PostgreSQL to query any kind of data source you can
> roll a driver for.  First one shipping reads CSV files, eliminating the
> need to COPY them into the database in many cases.

> * SEPostgres
> SE-Postgres has been integrated into PostgreSQL through generic security
> hooks and a contrib module.  Allows "military" level security/control
> over database.

Having just read the Beta announcement (well done!) I think we need to
explain what some of these features are a little more for the main
release.

I'm betting that only about 10% of people that care about databases
would know what SQL/MED is. Much better to say "Distributed Database
(Read-only)", or similar.

SE-Postgres isn't known to most people, and similarly, not everybody
has heard of SE-Linux or knows what its for.
How about "Generic Label Security, with integration to Security
Enhanced Linux (SELinux)"

Doesn't need to be more "marketingy" just more descriptive, fewer acronyms.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

On Mon, May 02, 2011 at 05:02:21PM +0100, Simon Riggs wrote:
> I'm betting that only about 10% of people that care about databases
> would know what SQL/MED is. Much better to say "Distributed Database
> (Read-only)", or similar.

At first glance, "distributed database" makes me think only of two-phase
commit, rather than SQL/MED. Perhaps it would be better to use words like
"management of external data" or "foreign data sources".

--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com

Joshua Tolley, 04.05.2011 15:02:
> On Mon, May 02, 2011 at 05:02:21PM +0100, Simon Riggs wrote:
>> I'm betting that only about 10% of people that care about databases
>> would know what SQL/MED is. Much better to say "Distributed Database
>> (Read-only)", or similar.
>
> At first glance, "distributed database" makes me think only of two-phase
> commit, rather than SQL/MED. Perhaps it would be better to use words like
> "management of external data" or "foreign data sources".

Oracle and Firebird call this "External tables".

Regards
Thomas

El mié, 04-05-2011 a las 07:02 -0600, Joshua Tolley escribió:
>
> At first glance, "distributed database" makes me think only of
> two-phase
> commit, rather than SQL/MED. Perhaps it would be better to use words
> like
> "management of external data" or "foreign data sources".

+1
--
Saludos,
Gilberto Castillo
Edificio Beijing. Miramar Trade Center. Etecsa.
Miramar, La Habana.Cuba.

Greg Smith wrote:
> On 04/03/2011 02:18 PM, Joshua Berkus wrote:
> > * Transaction-controlled Synch Rep
> > I would like to have volunteers from the advocacy list commit to taking on one of each of these features. For each one we need:
> >
> > a) a two-line explanation of what the feature is and why it's valuable (for the release notes, etc.)
> > b) a wiki page with a more detailed explaination and examples oriented towards the beginning-to-intermediate PostgreSQL user.
> >
>
> We already have http://wiki.postgresql.org/wiki/Synchronous_replication
> for sync rep, and I just started changing that around so that it
> reflects the code committed into 9.1. I got my first set of questions
> today suggesting our internal work on documenting this from the ground
> up is moving along. Over the next month we'll have at least two people
> chugging away at making that targeted more toward beginners (or split
> into something that is).
>
> I've been doing the elevator pitch for sync rep for a while now; here's
> a first draft description for the release notes:
>
> Transaction-controlled Synchronous Replication: When replicating to
> multiple nodes, customize every database transaction for its individual
> speed and durability needs. Options range from only committing to
> memory on the master up to the new synchronous standby mode, where data
> must be stored on multiple servers to be considered safe.

...

> PostgreSQL 9.1 lets you pick exactly the level of commit guarantee your
> data requires. Whether you want unlogged tables optimized only for
> speed, or you need durable synchronous replication to multiple servers,
> you're covered--all in one database.

I think the "users get control" montra could be a theme for this
release; I think it would apply to all of these:

* Unlogged tables to better handle some NoSQL workloads
* Synchronous replication for greater reliability
* SQL/MED (Management of External Data) (flat files, other databases)
* Per-column collation support
* Security Label, including SE-Linux integration
* True serializable isolation with predicate locking (already had snapshot isolation)

> Need to take a shower to wash the stench of marketing off now.

LOL

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +