Skip site navigation (1)
Skip section navigation (2)
Peripheral Links
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. +