Thread: Major features of 9.0?
All, Tommorrow is the end of CF4, and it's time to start working on the beta announcement for our beta release. To start with, I'd like to come up with our list of "big features" for 9.0 in addition to HS/SR. The ones I can see are: 64-bit Windows Support New Listen/Notify (event queueing support) -- if it makes it Exclusion constraints Default Privileges/Grant On ALL DO() statement Column Triggers Function call named parameters JSON/XML/YAML output for EXPLAIN Deferrable Unique Constraints Anything I'm missing? We're going to have to narrow this down to a "big 5" or "big 6". --Josh Berkus
2010/2/14 Josh Berkus <josh@agliodbs.com>: > All, > > Tommorrow is the end of CF4, and it's time to start working on the beta > announcement for our beta release. > > To start with, I'd like to come up with our list of "big features" for > 9.0 in addition to HS/SR. The ones I can see are: > > 64-bit Windows Support > New Listen/Notify (event queueing support) -- if it makes it > Exclusion constraints > Default Privileges/Grant On ALL > DO() statement > Column Triggers > Function call named parameters > JSON/XML/YAML output for EXPLAIN > Deferrable Unique Constraints > > Anything I'm missing? We're going to have to narrow this down to a "big > 5" or "big 6". join removal. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On 14/02/2010 19:39, Josh Berkus wrote: > 64-bit Windows Support > New Listen/Notify (event queueing support) -- if it makes it > Exclusion constraints > Default Privileges/Grant On ALL > DO() statement > Column Triggers > Function call named parameters > JSON/XML/YAML output for EXPLAIN > Deferrable Unique Constraints > > Anything I'm missing? We're going to have to narrow this down to a "big > 5" or "big 6". Did streaming replication (or whatever it was to be called) make it in? Also, how about writeable CTEs? Ray. -- Raymond O'Donnell :: Galway :: Ireland rod@iol.ie
On 14/02/2010 19:45, Raymond O'Donnell wrote: > On 14/02/2010 19:39, Josh Berkus wrote: >> 64-bit Windows Support >> New Listen/Notify (event queueing support) -- if it makes it >> Exclusion constraints >> Default Privileges/Grant On ALL >> DO() statement >> Column Triggers >> Function call named parameters >> JSON/XML/YAML output for EXPLAIN >> Deferrable Unique Constraints >> >> Anything I'm missing? We're going to have to narrow this down to a "big >> 5" or "big 6". > > Did streaming replication (or whatever it was to be called) make it in? > Also, how about writeable CTEs? Oops - just realised that's what HS/SR is. :-) Sorry for the noise. Ray. -- Raymond O'Donnell :: Galway :: Ireland rod@iol.ie
Josh Berkus <josh@agliodbs.com> writes: > To start with, I'd like to come up with our list of "big features" for > 9.0 in addition to HS/SR. The ones I can see are: > > 64-bit Windows Support > New Listen/Notify (event queueing support) -- if it makes it > Exclusion constraints > Default Privileges/Grant On ALL > DO() statement > Column Triggers > Function call named parameters > JSON/XML/YAML output for EXPLAIN > Deferrable Unique Constraints > > Anything I'm missing? We're going to have to narrow this down to a "big > 5" or "big 6". Some more: aggregate order by hstore improvements new VACUUM FULL which is usable, CLUSTER like plperl improvements application_name Trigger WHEN Perfs (rbtree, skip WAL in ALTER TABLE, tsearch url/email, join removal New Large Objects facilities and security My vote: 1. Integrated replication and read only slaves 2. Triggers on column and on when clause 3. Aggregate Order By 4. Deferrable Unique Constraints 5. Exclusion Constraints 6. Default Privileges/Grant On ALL 7. perfs I'm not sure if the big 5 or big 6 is meant to include integrated replication or not, so I went up to 7 items in the list. Regards, -- dim
All, First, Writeable CTE has just been sent back. Author fatigue, due to all of the wonky internals issues required to make it work properly. Second: let's divide this into 2 lists: (1) Top 5 *external* features other than HS/SR What I mean by this is features which will be important to people not yet using Postgres, and easily explanable to the press. Features that we can give a 2-4 word name to and people will understand what we mean. (2) Top 5 "internal" features other than HS/SR These are the niftiest features for people who *already use* PostgreSQL; improvements to admin, new SQL permutations, etc. Examples: (1) 64-bit Windows Support Built-in Event Queue (Listen/Notify) (2) Large Object improvements Aggregate Order By --Josh Berkus
I think Hstore improvements would be PR-worthy. It makes Postgres good for a class of EAV problems that were hard to deal with before and that people are looking at the NoSQL family of products (MongoDB, CouchDB, Voldemort, etc.) for; and that NoSQL stuff seem to be getting a lot of buzz in the press & conferences recently.
On 2/14/10 1:00 PM, Ron Mayer wrote: > I think Hstore improvements would be PR-worthy. It makes Postgres > good for a class of EAV problems that were hard to deal with before > and that people are looking at the NoSQL family of products (MongoDB, > CouchDB, Voldemort, etc.) for; and that NoSQL stuff seem to be > getting a lot of buzz in the press & conferences recently. "Advances in storing schemaless data"? ;-)
On Sun, Feb 14, 2010 at 01:47:44PM -0800, Josh Berkus wrote: > On 2/14/10 1:00 PM, Ron Mayer wrote: > > I think Hstore improvements would be PR-worthy. It makes Postgres > > good for a class of EAV problems that were hard to deal with before > > and that people are looking at the NoSQL family of products (MongoDB, > > CouchDB, Voldemort, etc.) for; and that NoSQL stuff seem to be > > getting a lot of buzz in the press & conferences recently. > > "Advances in storing schemaless data"? > > ;-) +1 from me, FWIW. It doesn't sound like schemaless data w/ hstore is a new thing for us; after all, hstore has been around for ages. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com
Attachment
Joshua Tolley wrote: -- Start of PGP signed section. > On Sun, Feb 14, 2010 at 01:47:44PM -0800, Josh Berkus wrote: > > On 2/14/10 1:00 PM, Ron Mayer wrote: > > > I think Hstore improvements would be PR-worthy. It makes Postgres > > > good for a class of EAV problems that were hard to deal with before > > > and that people are looking at the NoSQL family of products (MongoDB, > > > CouchDB, Voldemort, etc.) for; and that NoSQL stuff seem to be > > > getting a lot of buzz in the press & conferences recently. > > > > "Advances in storing schemaless data"? > > > > ;-) > > +1 from me, FWIW. It doesn't sound like schemaless data w/ hstore is a new > thing for us; after all, hstore has been around for ages. Isn't hstore key/value pair data, rather than schema-less. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
> Isn't hstore key/value pair data, rather than schema-less. Well, when the "NoSQL" people talk about "schemaless", that's what they mean. --Josh Berkus
* Josh Berkus: >> Isn't hstore key/value pair data, rather than schema-less. > > Well, when the "NoSQL" people talk about "schemaless", that's what they > mean. Some of them have got arbitrarily nested documents involving sequences, booleans, sequences of string/document pairs, strings, and floats. Positioning PostgreSQL's simple key/value support against that could be a PR mistake. 8-)
On Tue, Feb 16, 2010 at 11:02:39PM +0100, Florian Weimer wrote: > * Josh Berkus: > > >> Isn't hstore key/value pair data, rather than schema-less. > > > > Well, when the "NoSQL" people talk about "schemaless", that's what they > > mean. > > Some of them have got arbitrarily nested documents involving > sequences, booleans, sequences of string/document pairs, strings, and > floats. Positioning PostgreSQL's simple key/value support against > that could be a PR mistake. 8-) Yeah, I've got to agree on that point, and retract my earlier statement as overly broad. Yes, lots of NoSQL databases are simple key-value stores, but lots of them are significantly more than that. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com
Attachment
fw@deneb.enyo.de (Florian Weimer) writes: > * Josh Berkus: > >>> Isn't hstore key/value pair data, rather than schema-less. >> >> Well, when the "NoSQL" people talk about "schemaless", that's what they >> mean. > > Some of them have got arbitrarily nested documents involving > sequences, booleans, sequences of string/document pairs, strings, and > floats. Positioning PostgreSQL's simple key/value support against > that could be a PR mistake. 8-) And that points at the problem that "NoSQL" isn't a uniform thing; it's more a reaction against than a specific thing. <http://www.dbms2.com/2009/12/12/legit-nosql-key-value-store/> Here, it is pointed at as the conjunction of three things: a) Key/value stores (as some proposed here) b) Document managers (as you describe) c) DBMS imitations built atop something like Hadoop (which seems to revert into SQL) Monash suggests that the "legitimate" part is the distributed key/value stores. Those using CouchDB won't be thrilled with that! :-) A perhaps-related spectrum of questions comes in here... <http://www.dbms2.com/2009/12/11/nosql-q-and-a/> I think we'd need to have an answer for the CouchDB users in order to realistically make the claims. Note that there's a new Ubuntu thing called "Ubuntu One" <http://en.wikipedia.org/wiki/Ubuntu_One> which is a "cloud-based" storage/sync service analogous to Apple's iDisk/MobileMe (probably the most familiar thing of this sort). You can sync a variety of sorts of data, including the CouchDB databases containing contact info that can be used by various applications, using a substrate called "Desktop CouchDB" <https://launchpad.net/desktopcouch>. See <http://www.freedesktop.org/wiki/Specifications/desktopcouch> for more details on how they're trying to use it. What they're doing with CouchDB is fairly much "morally equivalent" to what one would do using LDAP. With the difference that what I've seen of CouchDB seems at least *somewhat* usable, whereas any time I touch LDAP I feel like I'd rather poke burning needles in my eyes... :-( In any case, let me reiterate... I think we'd need to have a way to duplicate the sort-of-schema-free model of CouchDB, and to manipulate it reasonably conveniently. Abstractly speaking, none of these things are truly "schemaless" - what they have done is to decide on a particular structure: - KV pair databases have the super-rigid schema that you have a single table with key/value pairs stored in it - Document databases are more or less like any/all of: a) LDAP hierarchies b) Forests of XML documents c) Bloated Goats, I mean, Lotus Notes It would be an interesting thing to have an API of some sort to enable conveniently storing document databases. That's not going to be in by 9.0 :-). It would be well worthwhile to have discussion of this at PGCon. -- let name="cbbrowne" and tld="acm.org" in name ^ "@" ^ tld;; http://linuxdatabases.info/info/slony.html "Fashion is a form of ugliness so intolerable that we have to alter it every six months." -- Oscar Wilde
On Tue, Feb 16, 2010 at 05:57:01PM -0500, Chris Browne wrote: > It would be an interesting thing to have an API of some sort to enable > conveniently storing document databases. That's not going to be in by > 9.0 :-). > > It would be well worthwhile to have discussion of this at PGCon. Ooo... sounds fun. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com
Attachment
On 2/16/10 4:17 PM, Joshua Tolley wrote: > On Tue, Feb 16, 2010 at 05:57:01PM -0500, Chris Browne wrote: >> It would be an interesting thing to have an API of some sort to enable >> conveniently storing document databases. That's not going to be in by >> 9.0 :-). >> >> It would be well worthwhile to have discussion of this at PGCon. > > Ooo... sounds fun. Heh, I was just talking to the Couch guys about "CouchGres". ;-) --Josh Berkus
On Tuesday 16 February 2010 17:02:39 Florian Weimer wrote: > * Josh Berkus: > >> Isn't hstore key/value pair data, rather than schema-less. > > > > Well, when the "NoSQL" people talk about "schemaless", that's what they > > mean. > > Some of them have got arbitrarily nested documents involving > sequences, booleans, sequences of string/document pairs, strings, and > floats. Positioning PostgreSQL's simple key/value support against > that could be a PR mistake. 8-) A better way to look at it is "improved support for storing semi-structured and un-structured data". Because we have pretty good support for that really, but these changes should make that somewhat better. -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com
On Mon, Feb 22, 2010 at 03:45:40PM -0500, Robert Treat wrote: > On Tuesday 16 February 2010 17:02:39 Florian Weimer wrote: > > * Josh Berkus: > > >> Isn't hstore key/value pair data, rather than schema-less. > > > > > > Well, when the "NoSQL" people talk about "schemaless", that's > > > what they mean. > > > > Some of them have got arbitrarily nested documents involving > > sequences, booleans, sequences of string/document pairs, strings, > > and floats. Positioning PostgreSQL's simple key/value support > > against that could be a PR mistake. 8-) > > A better way to look at it is "improved support for storing > semi-structured and un-structured data". Because we have pretty > good support for that really, but these changes should make that > somewhat better. There's a technical term we use for "un-structured data:" random bits. That other people use this misnomer isn't a reason we should perpetuate it. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.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 Monday 22 February 2010 16:10:40 David Fetter wrote: > On Mon, Feb 22, 2010 at 03:45:40PM -0500, Robert Treat wrote: > > On Tuesday 16 February 2010 17:02:39 Florian Weimer wrote: > > > * Josh Berkus: > > > >> Isn't hstore key/value pair data, rather than schema-less. > > > > > > > > Well, when the "NoSQL" people talk about "schemaless", that's > > > > what they mean. > > > > > > Some of them have got arbitrarily nested documents involving > > > sequences, booleans, sequences of string/document pairs, strings, > > > and floats. Positioning PostgreSQL's simple key/value support > > > against that could be a PR mistake. 8-) > > > > A better way to look at it is "improved support for storing > > semi-structured and un-structured data". Because we have pretty > > good support for that really, but these changes should make that > > somewhat better. > > There's a technical term we use for "un-structured data:" random bits. > That other people use this misnomer isn't a reason we should > perpetuate it. > ISTM the point of this list/discussion is to focus on marketing of Postgres. Given that, I don't think "improved support for storing random bits" is the direction we should be going in. -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com