Thread: 9.3 Beta 1 Coming Soon!
Folks,
PostgreSQL 9.3 Beta 1 is coming soon. As always, I could use your help
in coming up with some promotional text for the features it contains.
Here's the features I know of:
* declarative matviews
* better FK locks
* recursive views
* event triggers
* writeable foreign tables
* more JSON functions
* data checksums
* parallel pg_dump & dump directory format
* automatically updatable views
* streaming-only cascading replication failover
* configuration directory
* pg_isready (ping postgres)
* postgres_fdw
Others I missed?
We should pick 3-4 features which are worth talking about and promoting.
My thinking is:
* declarative matviews ("Materialized View Support")
* postgres_fdw / writeable foreign tables ("Federated Databases")
* event triggers
* JSON API and functions ("More JSON goodness")
However, I'm not quite sure how to explain Event Triggers to the general
public.
Also, while the JSON stuff is a minor feature compared to some of the
others (such as checksums), anything JSON gives us a lot of positive
press among web developers, hence why I'm thinking of including it.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
On 04/15/2013 03:23 PM, Josh Berkus wrote:
>
> We should pick 3-4 features which are worth talking about and promoting.
> My thinking is:
>
> * declarative matviews ("Materialized View Support")
> * postgres_fdw / writeable foreign tables ("Federated Databases")
> * event triggers
> * JSON API and functions ("More JSON goodness")
I am biased of course, but the FK Locks is rather huge in terms of an
overall improvement....
JD
--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC
@cmdpromptinc - 509-416-6579
> I am biased of course, but the FK Locks is rather huge in terms of an > overall improvement.... No question. It sucks for PR value though. Any summary of the feature will sound more like "we fixed a longstanding bug" than a real feature. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On 04/15/2013 03:23 PM, Josh Berkus wrote:
> Folks,
>
> PostgreSQL 9.3 Beta 1 is coming soon. As always, I could use your help
> in coming up with some promotional text for the features it contains.
> Here's the features I know of:
>
> * declarative matviews
> * better FK locks
> * recursive views
> * event triggers
> * writeable foreign tables
> * more JSON functions
> * data checksums
> * parallel pg_dump & dump directory format
> * automatically updatable views
> * streaming-only cascading replication failover
> * configuration directory
> * pg_isready (ping postgres)
> * postgres_fdw
>
> Others I missed?
>
> We should pick 3-4 features which are worth talking about and promoting.
> My thinking is:
>
> * declarative matviews ("Materialized View Support")
> * postgres_fdw / writeable foreign tables ("Federated Databases")
> * event triggers
> * JSON API and functions ("More JSON goodness")
>
> However, I'm not quite sure how to explain Event Triggers to the general
> public.
Yes, would require a good deal of copy.
My 2 cents, as top 5 with PR value:
declarative matviews ("Materialized View Support")
postgres_fdw / writeable foreign tables ("Federated Databases")
JSON API and functions ("More JSON goodness")
data checksums
streaming-only cascading replication failover
>
> Also, while the JSON stuff is a minor feature compared to some of the
> others (such as checksums), anything JSON gives us a lot of positive
> press among web developers, hence why I'm thinking of including it.
>
--
Adrian Klaver
adrian.klaver@gmail.com
Hi, On Mon, 2013-04-15 at 15:23 -0700, Josh Berkus wrote: > Others I missed? Noah, Kevin and Robert (Haas) told that the COPY FREEZE is also quite important as well. Extracted from Noah's words: "Reduce I/O arising from an initial table load by 75%". I would like to see this in important items list as well. Regards, -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
Attachment
On Apr 15, 2013, at 6:23 PM, Josh Berkus wrote:
> Folks,
>
> PostgreSQL 9.3 Beta 1 is coming soon. As always, I could use your help
> in coming up with some promotional text for the features it contains.
> Here's the features I know of:
>
> * declarative matviews
> * better FK locks
> * recursive views
> * event triggers
> * writeable foreign tables
> * more JSON functions
> * data checksums
> * parallel pg_dump & dump directory format
> * automatically updatable views
> * streaming-only cascading replication failover
> * configuration directory
> * pg_isready (ping postgres)
> * postgres_fdw
>
> Others I missed?
Was the work for outputting a query to a compressor of your choice committed? Not sure how to properly word this.
Also I believe there were SP-GiST improvements that speed up range type searches.
> We should pick 3-4 features which are worth talking about and promoting.
> My thinking is:
>
> * declarative matviews ("Materialized View Support")
> * postgres_fdw / writeable foreign tables ("Federated Databases")
> * event triggers
> * JSON API and functions ("More JSON goodness")
>
> However, I'm not quite sure how to explain Event Triggers to the general
> public.
>
> Also, while the JSON stuff is a minor feature compared to some of the
> others (such as checksums), anything JSON gives us a lot of positive
> press among web developers, hence why I'm thinking of including it.
A bunch of the new JSON functions are indexable, correct? That should provide some performance improvements when
searching,thus it would be good to play that up in addition to the functionality.
Jonathan
> Folks, > > PostgreSQL 9.3 Beta 1 is coming soon. As always, I could use your help > in coming up with some promotional text for the features it contains. > Here's the features I know of: > > * declarative matviews > * better FK locks > * recursive views > * event triggers > * writeable foreign tables > * more JSON functions > * data checksums > * parallel pg_dump & dump directory format > * automatically updatable views > * streaming-only cascading replication failover > * configuration directory > * pg_isready (ping postgres) > * postgres_fdw > > Others I missed? 64-bit large object API. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp > We should pick 3-4 features which are worth talking about and promoting. > My thinking is: > > * declarative matviews ("Materialized View Support") > * postgres_fdw / writeable foreign tables ("Federated Databases") > * event triggers > * JSON API and functions ("More JSON goodness") > > However, I'm not quite sure how to explain Event Triggers to the general > public. > > Also, while the JSON stuff is a minor feature compared to some of the > others (such as checksums), anything JSON gives us a lot of positive > press among web developers, hence why I'm thinking of including it. > > -- > Josh Berkus > PostgreSQL Experts Inc. > http://pgexperts.com > > > -- > Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-advocacy
2013/4/16 Josh Berkus <josh@agliodbs.com>: > Folks, > > PostgreSQL 9.3 Beta 1 is coming soon. As always, I could use your help > in coming up with some promotional text for the features it contains. > Here's the features I know of: > > * declarative matviews > * better FK locks > * recursive views > * event triggers > * writeable foreign tables > * more JSON functions > * data checksums > * parallel pg_dump & dump directory format > * automatically updatable views > * streaming-only cascading replication failover > * configuration directory > * pg_isready (ping postgres) > * postgres_fdw > > Others I missed? LATERAL keyword? Regards Ian Barwick
>> Others I missed? > > LATERAL keyword? Speaking of features which are hard to explain ... -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Mon, Apr 15, 2013 at 03:28:46PM -0700, Josh Berkus wrote: > > > I am biased of course, but the FK Locks is rather huge in terms of an > > overall improvement.... > > No question. It sucks for PR value though. Any summary of the feature > will sound more like "we fixed a longstanding bug" than a real feature. I will certainly have a description in the release notes, that perhaps you can use. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Mon, Apr 15, 2013 at 05:12:49PM -0700, Josh Berkus wrote: > > >> Others I missed? > > > > LATERAL keyword? > > Speaking of features which are hard to explain ... Tom says LATERAL is useful when you are using a column from one of the FROM clause tables in a set-returning function that is also in the FROM clause. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
2013/4/16 Ian Lawrence Barwick <barwick@gmail.com>: > 2013/4/16 Josh Berkus <josh@agliodbs.com>: >> >>>> Others I missed? >>> >>> LATERAL keyword? >> >> Speaking of features which are hard to explain ... (apologies for the resubmission, I got a strange message from the list software saying the mail was stalled due to the use of the word "w h i c h" followed by another word) Well you were asking for a list of features... but yeah, it's not one that might make great headline material. OTOH, it is kind of nifty when working with SRFs; once I got my head around it I realized it was a feature I've been missing pretty much since SRFs first appeared. Do you use set-returning functions a lot? Do you get frustrated by the error message "function expression in FROM cannot refer to other relations of same query level" and find yourself wondering if there's an easier way of integrating SRFs directly into FROM clauses? Then PostgreSQL 9.3's all-new LATERAL keyword is your new bestest friend and will revolutionize your life (for certain values of revolution)! Dunno if it's any use, but I collated a list of blog articles on 9.3 features: http://sql-info.de/postgresql/notes/postgresql-9.3-feature-preview-articles.html Regards Ian Barwick
2013/4/16 Josh Berkus <josh@agliodbs.com>: > >>> Others I missed? >> >> LATERAL keyword? > > Speaking of features which are hard to explain ... Well you were asking for a list of features... but yeah, it's not one which would make great headline material. OTOH, it is kind of nifty when working with SRFs; once I got my head around it I realized it was a feature I've been missing pretty much since SRFs first appeared. Do you use set-returning functions a lot? Do you get frustrated by the error message "function expression in FROM cannot refer to other relations of same query level" and find yourself wondering if there's an easier way of integrating SRFs directly into FROM clauses? Then PostgreSQL 9.3's all-new LATERAL keyword is your new bestest friend and will revolutionize your life (for certain values of revolution)! Dunno if it's any use, but I collated a list of blog articles on 9.3 features: http://sql-info.de/postgresql/notes/postgresql-9.3-feature-preview-articles.html Regards Ian
On 15 April 2013 23:23, Josh Berkus <josh@agliodbs.com> wrote: > * declarative matviews > * event triggers Regrettably the state of both of those features is nowhere near complete enough for wide production use. Highlighting them as tier 1 items would be misleading. If there is a way to say these are good steps towards the full feature set people expect then it will work. Initial, basic, entry level etc.. (Note that I'm not commenting on the internal implementation, just the user facing feature set). If we say we have something when we don't we let down our users, reduce our reputation and stifle any chance of improving them later, since people say "I thought we already had those?". Partitioning fell into the same problem and I'd like to avoid that. > * streaming-only cascading replication failover Do you mean the fast failover option? > * configuration directory configuration directories -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Tue, Apr 16, 2013 at 9:51 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > On 15 April 2013 23:23, Josh Berkus <josh@agliodbs.com> wrote: > >> * declarative matviews >> * event triggers > > Regrettably the state of both of those features is nowhere near > complete enough for wide production use. Highlighting them as tier 1 > items would be misleading. If there is a way to say these are good > steps towards the full feature set people expect then it will work. > Initial, basic, entry level etc.. (Note that I'm not commenting on the > internal implementation, just the user facing feature set). I was just about to make that comment. Particularly when it comes to matviews. However, we highlighted the json datatype pretty well in 9.2 and it gave us a lot of good press. But it doesn't really *do* anything in 9.2 - kind of like matviews. 9.3 will make json a lot more useful - as hopefully 9.4 can improve on the matviews. But if it's marketing only, then the feature is there I guess... >> * streaming-only cascading replication failover > > Do you mean the fast failover option? I think he's referring to timeline switching over streaming replication. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On 15 April 2013 23:23, Josh Berkus <josh@agliodbs.com> wrote: > Folks, > > PostgreSQL 9.3 Beta 1 is coming soon. As always, I could use your help > in coming up with some promotional text for the features it contains. > Here's the features I know of: > > * declarative matviews > * better FK locks > * recursive views > * event triggers > * writeable foreign tables > * more JSON functions > * data checksums > * parallel pg_dump & dump directory format > * automatically updatable views > * streaming-only cascading replication failover > * configuration directory > * pg_isready (ping postgres) > * postgres_fdw > > Others I missed? This list should cover all the main features: http://en.wikipedia.org/wiki/Postgresql#Upcoming_features -- Thom
On 16 April 2013 08:54, Magnus Hagander <magnus@hagander.net> wrote: >>> * streaming-only cascading replication failover >> >> Do you mean the fast failover option? > > I think he's referring to timeline switching over streaming replication. Then we should mention fast failover, since it allows us to get to 5 nines availability. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 16 April 2013 08:54, Magnus Hagander <magnus@hagander.net> wrote: > However, we highlighted the json datatype pretty well in 9.2 and it > gave us a lot of good press. But it doesn't really *do* anything in > 9.2 - kind of like matviews. 9.3 will make json a lot more useful - as > hopefully 9.4 can improve on the matviews. But if it's marketing only, > then the feature is there I guess... If we want good marketing then we need good features as the first step. If the argument is that it doesn't matter if a feature gets punted to the next release, then we can punt the marketing also. We will collect both the feature and the kudos soon enough. If we try to collect the kudos early all we do is set the expectation that you need to wait until the release after we announce something before it is fully usable. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Josh Berkus <josh@agliodbs.com> writes: > Others I missed? Regexp indexing is big enough to be there, I think. -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Simon Riggs <simon@2ndQuadrant.com> writes: > On 15 April 2013 23:23, Josh Berkus <josh@agliodbs.com> wrote: > >> * declarative matviews >> * event triggers > > Regrettably the state of both of those features is nowhere near > complete enough for wide production use. Highlighting them as tier 1 > items would be misleading. If there is a way to say these are good > steps towards the full feature set people expect then it will work. > Initial, basic, entry level etc.. (Note that I'm not commenting on the > internal implementation, just the user facing feature set). Yes, please don't mention Event Triggers anywhere. You can not solve a single problem with them that you couldn't already solve before with a hook, and you need to be using C to access any interesting data. As a user, Event Triggers just don't exist in 9.3, full stop. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Le 16/04/2013 00:23, Josh Berkus a écrit :
> Folks,
>
> PostgreSQL 9.3 Beta 1 is coming soon. As always, I could use your help
> in coming up with some promotional text for the features it contains.
> Here's the features I know of:
>
> * declarative matviews
> * better FK locks
> * recursive views
> * event triggers
> * writeable foreign tables
> * more JSON functions
> * data checksums
> * parallel pg_dump & dump directory format
> * automatically updatable views
> * streaming-only cascading replication failover
> * configuration directory
> * pg_isready (ping postgres)
> * postgres_fdw
>
> Others I missed?
>
Custom background worker processes ?
Definitively not a top 3 feature but it's promising and it could be
interesting to attract some developer attention on this feature...
> We should pick 3-4 features which are worth talking about and promoting.
> My thinking is:
>
> * declarative matviews ("Materialized View Support")
> * postgres_fdw / writeable foreign tables ("Federated Databases")
> * event triggers
> * JSON API and functions ("More JSON goodness")
>
My personal "pure-PR" top :
* Material Views
* JSON parser and more
* postgres_fdw + writeable foreign tables
>> * declarative matviews >> * event triggers > > Regrettably the state of both of those features is nowhere near > complete enough for wide production use. Per Dimitri that's true of Event Triggers, but per my prior post on the topic on this mailing list, it's not true of Materialized Views. As I've said before, we get one, and only one, chance to promote a new feature and that's when the feature first appears in a PostgreSQL release *however incomplete it is*. If we try to promote it in a successive release when it's "more finished", we will get zero traction with the press. It's not news. Aside from that, the MatView feature in the state it's in now is useful to *me*, even if it's not useful to *you*. And I think that my use-cases represent some hundreds or thousands of DBAs, so it's worth promoting so that they will know about it. Lets not let the perfect be the enemy of the good here. >> * streaming-only cascading replication failover > > Do you mean the fast failover option? No, I mean the ability to remaster using only streaming replication. As Simon points out, this could be combined with fast failover into one "feature" in our PR. > Regexp indexing is big enough to be there, I think. > Ooooh! That got in? > Custom background worker processes ? > > Definitively not a top 3 feature but it's promising and it could be > interesting to attract some developer attention on this feature... Seems to me that becomes a feature once we have at least one example useful worker. Any idea if someone is building one before 9.3.0? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On 2013-04-16 09:45:17 -0700, Josh Berkus wrote: > > >> * declarative matviews > >> * event triggers > > > > Regrettably the state of both of those features is nowhere near > > complete enough for wide production use. > > Per Dimitri that's true of Event Triggers, but per my prior post on the > topic on this mailing list, it's not true of Materialized Views. As > I've said before, we get one, and only one, chance to promote a new > feature and that's when the feature first appears in a PostgreSQL > release *however incomplete it is*. If we try to promote it in a > successive release when it's "more finished", we will get zero traction > with the press. It's not news. We had CREATE FOREIGN DATA WRAPPER without it doing much and added stuff later. And we still can now promote postgres_fdw. We had views before, but they weren't auto-updateable. We can promote that now... > Aside from that, the MatView feature in the state it's in now is useful > to *me*, even if it's not useful to *you*. And I think that my > use-cases represent some hundreds or thousands of DBAs, so it's worth > promoting so that they will know about it. > > Lets not let the perfect be the enemy of the good here. I think that will lead to a future where we can't commit intermediate states of work since we now it will be used for PR regardless of its state. I am pretty sure several people would have voiced loud(er) objections for matviews to be commited if they would have known the end result of it being rather incomplete and promoted anyway. And that will hurt postgres. > > Regexp indexing is big enough to be there, I think. > > > > Ooooh! That got in? Yup, Tom committed it on the 9th. Really rather cool stuff. > > Custom background worker processes ? > > > > Definitively not a top 3 feature but it's promising and it could be > > interesting to attract some developer attention on this feature... > Seems to me that becomes a feature once we have at least one example > useful worker. Any idea if someone is building one before 9.3.0? We are actively using it for the development of BDR, not sure if thats an interesting enough example because the whole thing is far bigger than that piece. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Mon, Apr 15, 2013 at 05:12:49PM -0700, Josh Berkus wrote: > > >> Others I missed? > > > > LATERAL keyword? > > Speaking of features which are hard to explain ... ...and hard to do without once you have them :) It's worth a mention, I think. 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
Andres, > We had CREATE FOREIGN DATA WRAPPER without it doing much and added stuff ... and we promoted it when it was introduced. > I think that will lead to a future where we can't commit intermediate > states of work since we now it will be used for PR regardless of its > state. I am pretty sure several people would have voiced loud(er) > objections for matviews to be commited if they would have known the end > result of it being rather incomplete and promoted anyway. And that will > hurt postgres. I simply don't agree that the matview feature, as it exists in 9.3, is sucky and not worth talking about. As I have said before, I think the feature we have is useful now even if it's not as useful as it will be later. We can promote a feature, but still mention its limitations and ongoing work. We've done that plenty of times before. >> Seems to me that becomes a feature once we have at least one example >> useful worker. Any idea if someone is building one before 9.3.0? > > We are actively using it for the development of BDR, not sure if thats > an interesting enough example because the whole thing is far bigger than > that piece. Yeah, and that's unlikely to be done before September. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On 04/16/2013 02:46 AM, Ian Lawrence Barwick wrote: > OTOH, it is kind of nifty when working with SRFs; once I got my head around it > I realized it was a feature I've been missing pretty much since SRFs > first appeared. > > Do you use set-returning functions a lot? > Do you get frustrated by the error message "function expression in > FROM cannot refer to other relations of same query level" and find > yourself wondering if there's an easier way of integrating SRFs > directly into FROM clauses? > Then PostgreSQL 9.3's all-new LATERAL keyword is your new bestest > friend and will revolutionize your life (for certain values of > revolution)! Tom fixed so LATERAL is implicit for set retuning functions so the LATERAL keyword is now only required for subqueries. http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=2378d79ab29865f59245744beb8f04a3ce56d2ae To me personally the addition of LATERAL might be the most important new feature in 9.3 (together with the FK locks), and something I have wished for a long time. But I do understand it might be hard to explain and use in marketing. -- Andreas Karlsson
On 04/16/2013 06:45 PM, Josh Berkus wrote: > Aside from that, the MatView feature in the state it's in now is useful > to *me*, even if it's not useful to *you*. And I think that my > use-cases represent some hundreds or thousands of DBAs, so it's worth > promoting so that they will know about it. If it is promoted I think it is important to make sure it is clearly stated what is in the release and what is not. Including the lock level of REFRESH which currently is not well documented. -- Andreas Karlsson
> "Postgres developers and users believe that quality view support is an > important toolset for any database, and Postgres 9.3 includes several > improvements to it's view support. Enhancements included in this > release include the ability to create recursive views, to create > automatically updateable views, and limited support for built in > materialized views." I still think that's soft-pedaling it far to much. If we don't toot our own horn, who will? And "View improvements" is a pretty darned weak promotional message compared to "Materialized View Declaration". Regrading MatViews, let me explain why the Refresh locking isn't the albatross which some people think it is. Currently, my clients, and several OSS projects, have many applications which currently use tables as materialized views. The common way to handle these is "BEGIN; TRUNCATE matview; INSERT INTO matview SELECT ...; COMMIT;". This produces the *exact same* locking pattern as the current REFRESH. While more lock-sensitive patterns are possible, that doesn't mean people are, in the mainstream, using them. Thus 9.3 Matviews allow DB architects to do a task they have been doing, with simpler, less code, and no loss of functionality. Further, with simpler, more mainainable code, we can expect app developers who haven't previously used matviews as a concept to try them. Further, we'll have increases in functionality in the future (CONCURRENTLY in 9.4, async/sync updates later, incremental updates, etc.), which never would exist in an ad-hoc system, and which probably won't require any changes in code built on 9.3 to take advantage of. The purpose of advocacy, and release announcements, is to *promote* PostgreSQL, not to advertise every bug we have and every limitation. Nitpicky perfectionism may be useful when we're writing code, but it seriously undermines the project if it appears in our advocacy materials. What other open source DBMS even has the concept of materialized views? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
All, Can someone come up with an example of how to use the new Regex indexing? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Apr 17, 2013, at 12:51 PM, Josh Berkus wrote: > >> "Postgres developers and users believe that quality view support is an >> important toolset for any database, and Postgres 9.3 includes several >> improvements to it's view support. Enhancements included in this >> release include the ability to create recursive views, to create >> automatically updateable views, and limited support for built in >> materialized views." > > The purpose of advocacy, and release announcements, is to *promote* > PostgreSQL, not to advertise every bug we have and every limitation. > Nitpicky perfectionism may be useful when we're writing code, but it > seriously undermines the project if it appears in our advocacy > materials. What other open source DBMS even has the concept of > materialized views? I agree on that, but also on that note, we do have future opportunities to promote feature improvements as news. Once wedo have full support for materialized views, that is still news, much like the JSON improvements are newsworthy in 9.3too, even though JSON support was released in 9.2. New features are not limited to "one shot" of press. We should promote materialized views now knowing full well we can alwayspromote them again later, even if it's something as simple as "new materialized views support" - it sounds like it'sbrand new, even if it is just enhanced. Jonathan
On 17 April 2013 17:52, Josh Berkus <josh@agliodbs.com> wrote: > All, > > Can someone come up with an example of how to use the new Regex indexing? There's an example in the dev docs: http://www.postgresql.org/docs/devel/static/pgtrgm.html#AEN147751 -- Thom
On 04/17/2013 04:59 AM, Robert Treat wrote: > "Postgres developers and users believe that quality view support is an > important toolset for any database, and Postgres 9.3 includes several > improvements to it's view support. Enhancements included in this > release include the ability to create recursive views, to create > automatically updateable views, and limited support for built in > materialized views." So, taking a second stab at this: Database VIEWs allow application developers to abstract database access, making application code simpler and version migrations easier. As such, PostgreSQL has improved our view support: * Materialized View declaration * Auto-updatable VIEWs * Recursive Views I think that puts the new features more strongly, and also explains how views relate to the reader. Yes? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
> So, taking a second stab at this: > > Database VIEWs allow application developers to abstract database access, > making application code simpler and version migrations easier. As such, > PostgreSQL has improved our view support: > * Materialized View declaration > * Auto-updatable VIEWs > * Recursive Views > > I think that puts the new features more strongly, and also explains how > views relate to the reader. Yes? I like it - shows multiple improvements to heavily used functionality, while glossing over the incomplete nature of mat views. It also focuses on "View Improvements" instead of one specific improvement/feature, which compactly sends a "multipleimprovement" message. Specifically, the mat view stuff is nice, but the updatable views is going to be massivefor a lot of people. That's a feature that would have save me a lot of time in the past. On another note - are page checksums going to make the cut? While not exactly flashy, that is a really critical featurefor mission critical systems - something we have sorely lacked. Brad
On Wed, Apr 17, 2013 at 08:09:10PM +0000, Nicholson, Brad (Toronto, ON, CA) wrote: > On another note - are page checksums going to make the cut? While not > exactly flashy, that is a really critical feature for mission critical > systems - something we have sorely lacked. Page checksums are in, but we are now debating the algorithm. :-( -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Hi, Am Dienstag, den 16.04.2013, 10:29 +0200 schrieb Dimitri Fontaine: > Josh Berkus <josh@agliodbs.com> writes: > > Others I missed? > > Regexp indexing is big enough to be there, I think. Yeah. On that note, does anybody else have general-purpose regexp indexing? I did a quick google search the other day, but could only come up with "have to write a .NET plugin" (for SQL Server) and "have to specify the regexp during index creation" (for Oracle). That wasn't an exhaustive search, though, of course. Michael -- Michael Banck Tel.: +49 (0) 2161 / 4643-171 credativ GmbH, HRB Mönchengladbach 12080 Hohenzollernstr. 133, 41061 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz
On 4/17/13 1:50 PM, Josh Berkus wrote: > So, taking a second stab at this: > > Database VIEWs allow application developers to abstract database access, > making application code simpler and version migrations easier. As such, > PostgreSQL has improved our view support: > * Materialized View declaration > * Auto-updatable VIEWs Except that materialized views aren't auto-updatable, so it would be quite confusing to lump those together. > * Recursive Views You could do recursive views before. There is just now a more compact syntax for it.
On 17 April 2013 17:51, Josh Berkus <josh@agliodbs.com> wrote: > Regrading MatViews, let me explain why the Refresh locking isn't the > albatross which some people think it is. Currently, my clients, and > several OSS projects, have many applications which currently use tables > as materialized views. The common way to handle these is "BEGIN; > TRUNCATE matview; INSERT INTO matview SELECT ...; COMMIT;". This > produces the *exact same* locking pattern as the current REFRESH. While > more lock-sensitive patterns are possible, that doesn't mean people are, > in the mainstream, using them. I agree that the above code has exactly the same locking pattern as a refresh. Only trouble is that isn't the best way of doing it, nor in my experience the common way of doing it. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 17 April 2013 18:50, Josh Berkus <josh@agliodbs.com> wrote: > On 04/17/2013 04:59 AM, Robert Treat wrote: >> "Postgres developers and users believe that quality view support is an >> important toolset for any database, and Postgres 9.3 includes several >> improvements to it's view support. Enhancements included in this >> release include the ability to create recursive views, to create >> automatically updateable views, and limited support for built in >> materialized views." > > > So, taking a second stab at this: > > Database VIEWs allow application developers to abstract database access, > making application code simpler and version migrations easier. As such, > PostgreSQL has improved our view support: > * Materialized View declaration > * Auto-updatable VIEWs > * Recursive Views As a headline item, I think "New and advanced features for Views" makes sense. Taking all of the above together its clearly a great set of related features. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
So, taking a stab at the list again, I realize I forgot a *major* feature: no more SHMMAX/SHMALL thanks to posix shmem. I also think that a good writeup of "federated databases" as a "group" of features would be cool. Does anyone know exactly which parts of pgsql_fdw got in and which are waiting for 9.4? I lost track. Did join pushdown get in, for example? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On 17/04/13 07:53, David Fetter wrote:
Isn't 'Lateral Thinking' something we are meant to do more of? :-)On Mon, Apr 15, 2013 at 05:12:49PM -0700, Josh Berkus wrote:Others I missed?LATERAL keyword?Speaking of features which are hard to explain ......and hard to do without once you have them :) It's worth a mention, I think. Cheers, David.
Nice to weave in to the mention of the 'LATERAL' keyword, but I fear that it would confuse more than it would amuse!
Cheers,
Gavin
On Tue, Apr 16, 2013 at 10:53 PM, Josh Berkus <josh@agliodbs.com> wrote: > Andres, > >> We had CREATE FOREIGN DATA WRAPPER without it doing much and added stuff > > ... and we promoted it when it was introduced. > >> I think that will lead to a future where we can't commit intermediate >> states of work since we now it will be used for PR regardless of its >> state. I am pretty sure several people would have voiced loud(er) >> objections for matviews to be commited if they would have known the end >> result of it being rather incomplete and promoted anyway. And that will >> hurt postgres. > That seems like a bit of a straw man; partial support for event triggers was committed, there have been objections raised to it's useful and inclusion as PR, and so we've backed away from it. > I simply don't agree that the matview feature, as it exists in 9.3, is > sucky and not worth talking about. As I have said before, I think the > feature we have is useful now even if it's not as useful as it will be > later. > > We can promote a feature, but still mention its limitations and ongoing > work. We've done that plenty of times before. > Maybe another path to take is to bundle all of the view related features together: "Postgres developers and users believe that quality view support is an important toolset for any database, and Postgres 9.3 includes several improvements to it's view support. Enhancements included in this release include the ability to create recursive views, to create automatically updateable views, and limited support for built in materialized views." Robert Treat conjecture: xzilla.net consulting: omniti.com
Andreas Karlsson escribió: > Tom fixed so LATERAL is implicit for set retuning functions so the > LATERAL keyword is now only required for subqueries. > > http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=2378d79ab29865f59245744beb8f04a3ce56d2ae That's correct; but even without the keyword, the implementation of the feature was necessary for lateral references of SRFs to work sanely. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Folks, So, here's what we potentially have as "worth mentioning": * Views (updatable, matviews) * Federation (writeable fdw, pgsql_fdw) * LATERAL * regex indexes * No more SHMMAX/SHMMALL Is that everything? You know, I'm not really seeing a "theme" here. 9.3 seems like more of a "cleanup" version ... -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On 04/19/2013 09:41 AM, Josh Berkus wrote: > Folks, > > So, here's what we potentially have as "worth mentioning": > > * Views (updatable, matviews) > * Federation (writeable fdw, pgsql_fdw) > * LATERAL > * regex indexes > * No more SHMMAX/SHMMALL Feh. * More JSON stuff I'm having a "seven dwarves" issue ... > > Is that everything? > > You know, I'm not really seeing a "theme" here. 9.3 seems like more of > a "cleanup" version ... > -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Wed, Apr 17, 2013 at 07:59:50AM -0400, Robert Treat wrote: > On Tue, Apr 16, 2013 at 10:53 PM, Josh Berkus <josh@agliodbs.com> wrote: > > Andres, > > > >> We had CREATE FOREIGN DATA WRAPPER without it doing much and added stuff > > > > ... and we promoted it when it was introduced. > > > >> I think that will lead to a future where we can't commit intermediate > >> states of work since we now it will be used for PR regardless of its > >> state. I am pretty sure several people would have voiced loud(er) > >> objections for matviews to be commited if they would have known the end > >> result of it being rather incomplete and promoted anyway. And that will > >> hurt postgres. > > > > That seems like a bit of a straw man; partial support for event > triggers was committed, there have been objections raised to it's > useful and inclusion as PR, and so we've backed away from it. > > > I simply don't agree that the matview feature, as it exists in 9.3, is > > sucky and not worth talking about. As I have said before, I think the > > feature we have is useful now even if it's not as useful as it will be > > later. > > > > We can promote a feature, but still mention its limitations and ongoing > > work. We've done that plenty of times before. > > > > Maybe another path to take is to bundle all of the view related > features together: > > "Postgres developers and users believe that quality view support is an > important toolset for any database, and Postgres 9.3 includes several > improvements to it's view support. Enhancements included in this > release include the ability to create recursive views, I don't think the recursive views are really worth mentioning, as they're just a SQL spec compliant wrapper around what we can already do with the regular CREATE VIEW AS ... WITH ... syntax. I'm all for spec compliance, but there's just no new capability added here. > to create automatically updateable views, and limited support for > built in materialized views." These two, in contrast, are *very* handy. Yes, you could have done both of these things before, and many of us did, but it was a *lot* more work, and a lot more error-prone. 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 Thu, Apr 18, 2013 at 02:20:09PM -0700, Josh Berkus wrote: > So, taking a stab at the list again, I realize I forgot a *major* > feature: no more SHMMAX/SHMALL thanks to posix shmem. > > I also think that a good writeup of "federated databases" as a "group" > of features would be cool. Does anyone know exactly which parts of > pgsql_fdw got in and which are waiting for 9.4? I lost track. Did join > pushdown get in, for example? Yes :) Look for "join" in postgres_fdw, for example :) :) 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 Fri, April 19, 2013 18:43, Josh Berkus wrote: > On 04/19/2013 09:41 AM, Josh Berkus wrote: >> Folks, >> >> So, here's what we potentially have as "worth mentioning": >> >> * Views (updatable, matviews) >> * Federation (writeable fdw, pgsql_fdw) >> * LATERAL >> * regex indexes >> * No more SHMMAX/SHMMALL > * More JSON stuff Checksums ? (even if it's not quite ready :-))
On 04/19/2013 02:16 PM, Erikjan Rijkers wrote: > On Fri, April 19, 2013 18:43, Josh Berkus wrote: >> On 04/19/2013 09:41 AM, Josh Berkus wrote: >>> Folks, >>> >>> So, here's what we potentially have as "worth mentioning": >>> >>> * Views (updatable, matviews) >>> * Federation (writeable fdw, pgsql_fdw) >>> * LATERAL >>> * regex indexes >>> * No more SHMMAX/SHMMALL >> * More JSON stuff > > Checksums ? (even if it's not quite ready :-)) Feh, this is really a "grab bag" release, isn't it? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Apr 19, 2013, at 5:52 PM, Josh Berkus wrote:
> On 04/19/2013 02:16 PM, Erikjan Rijkers wrote:
>> On Fri, April 19, 2013 18:43, Josh Berkus wrote:
>>> On 04/19/2013 09:41 AM, Josh Berkus wrote:
>>>> Folks,
>>>>
>>>> So, here's what we potentially have as "worth mentioning":
>>>>
>>>> * Views (updatable, matviews)
>>>> * Federation (writeable fdw, pgsql_fdw)
>>>> * LATERAL
>>>> * regex indexes
>>>> * No more SHMMAX/SHMMALL
>>> * More JSON stuff
>>
>> Checksums ? (even if it's not quite ready :-))
>
> Feh, this is really a "grab bag" release, isn't it?
I think it's a testament to how strong the last several releases have been. This is an "enhancement release" on top of
allthe major features that have been added to the 9.x series, and while it might not be as flashy as "{async, sync}
streamingreplication" or hot standbys, this release provides a good opportunity to build on the work of the earlier 9.x
releases.
By framing it as a "building on the work of XYZ from 9.2" we can promote all the enhancements that 9.3 offers.
Jonathan
> By framing it as a "building on the work of XYZ from 9.2" we can promote all the enhancements that 9.3 offers. Yeah, we'll still need some coherent messaging for the final release. Not sure what that will be. Our last "grab bag" release was 8.4, where we went with the message "easier than ever!". Not sure what we want this time. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On 04/19/2013 03:11 PM, Josh Berkus wrote: > > >> By framing it as a "building on the work of XYZ from 9.2" we can promote all the enhancements that 9.3 offers. > > Yeah, we'll still need some coherent messaging for the final release. > Not sure what that will be. Our last "grab bag" release was 8.4, where > we went with the message "easier than ever!". Not sure what we want > this time. > Making the competition quake in their boots! -- Command Prompt, Inc. - http://www.commandprompt.com/ PostgreSQL Support, Training, Professional Services and Development High Availability, Oracle Conversion, Postgres-XC @cmdpromptinc - 509-416-6579
>> By framing it as a "building on the work of XYZ from 9.2" we can promote all the enhancements that 9.3 offers. > > Yeah, we'll still need some coherent messaging for the final release. > Not sure what that will be. Our last "grab bag" release was 8.4, where > we went with the message "easier than ever!". Not sure what we want > this time. Hi. Mac OS X Snow Leopard was advertised as an improved Leopard, without lots of new features added. Some tag lines they used were: "Core innovation" and "The world's most advanced operating system. Finely tuned." We could use someting along those lines... Bye, Chris.
On Wed, Apr 17, 2013 at 1:45 AM, Josh Berkus <josh@agliodbs.com> wrote: >>> * streaming-only cascading replication failover >> >> Do you mean the fast failover option? > > No, I mean the ability to remaster using only streaming replication. I don't think this has been committed. You still need to take a fresh backup when starting crashed master as new standby after failover. > As > Simon points out, this could be combined with fast failover into one > "feature" in our PR. Yes, fast failover is really useful feature for HA. Regards, -- Fujii Masao
Hi guys, Il 19/04/13 18:41, Josh Berkus ha scritto: > You know, I'm not really seeing a "theme" here. 9.3 seems like more of > a "cleanup" version ... > What I suggest this time is to avoid mentioning all the new features in the beta announcement, reducing the impact of the 9.3.0 official release. We faced this problem last year too, when we had to make the announcement and ... everything had already been said in the beta1 release. This would also give us more time to prepare an effective official release announcement. In the meantime we could prepare a 9.3 wiki page with all the new features (making sure everyone understands it is still a beta version) and in the beta and rc releases we simply refer to this page. Ciao, Gabriele -- Gabriele Bartolini - 2ndQuadrant Italia PostgreSQL Training, Services and Support gabriele.bartolini@2ndQuadrant.it | www.2ndQuadrant.it
On 19 April 2013 22:16, Erikjan Rijkers <er@xs4all.nl> wrote: > Checksums ? (even if it's not quite ready :-)) Checksums are ready.... The only discussion point is the exact CRC algorithm and the performance of it. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 2013-04-20 08:32:58 +0200, Gabriele Bartolini wrote: > Hi guys, > > Il 19/04/13 18:41, Josh Berkus ha scritto: > >You know, I'm not really seeing a "theme" here. 9.3 seems like more of > >a "cleanup" version ... > > > What I suggest this time is to avoid mentioning all the new features in the > beta announcement, reducing the impact of the 9.3.0 official release. We > faced this problem last year too, when we had to make the announcement and > ... everything had already been said in the beta1 release. I think this is dangerous as it reduces the amount of testing those new features get even further. We *need* the testing. And for that the testers need to know about the new features. Otherwise we can just skip beta. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 20 April 2013 11:10, Andres Freund <andres@2ndquadrant.com> wrote: > On 2013-04-20 08:32:58 +0200, Gabriele Bartolini wrote: >> Hi guys, >> >> Il 19/04/13 18:41, Josh Berkus ha scritto: >> >You know, I'm not really seeing a "theme" here. 9.3 seems like more of >> >a "cleanup" version ... >> > >> What I suggest this time is to avoid mentioning all the new features in the >> beta announcement, reducing the impact of the 9.3.0 official release. We >> faced this problem last year too, when we had to make the announcement and >> ... everything had already been said in the beta1 release. > > I think this is dangerous as it reduces the amount of testing those new > features get even further. We *need* the testing. And for that the > testers need to know about the new features. Otherwise we can just skip > beta. ISTM that if we wrote the list of Good Features *after* we wrote the release notes we'd stand a better chance of doing it well. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Fri, 2013-04-19 at 14:52 -0700, Josh Berkus wrote: > Feh, this is really a "grab bag" release, isn't it? Every release is a grab bag release, as it should be. Everything else is just editorializing after the fact. The appeal of "themed" release is very limited for people who don't use whatever the theme is supposed to be.
Fujii,
> I don't think this has been committed. You still need to take a fresh backup
> when starting crashed master as new standby after failover.
I'm talking about:
m1 --> r1 --> r2
|
|
V
r3
m1 fails. Promote r1 to the new master. This works as you'd expect
now; it didn't in 9.2.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
>> What I suggest this time is to avoid mentioning all the new features in the >> beta announcement, reducing the impact of the 9.3.0 official release. We >> faced this problem last year too, when we had to make the announcement and >> ... everything had already been said in the beta1 release. > > I think this is dangerous as it reduces the amount of testing those new > features get even further. We *need* the testing. And for that the > testers need to know about the new features. Otherwise we can just skip > beta. I have to agree with Andres, here. Good PR is nice, but good testing is more important. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
Hi, Am Freitag, den 19.04.2013, 09:41 -0700 schrieb Josh Berkus: > So, here's what we potentially have as "worth mentioning": > > * Views (updatable, matviews) > * Federation (writeable fdw, pgsql_fdw) > * LATERAL > * regex indexes > * No more SHMMAX/SHMMALL > > Is that everything? I am not sure "No more SHMMAX/SHMMALL" should be in the top 5 - it is quite nice that DBAs do not have to fiddle with it anyway, but will it make people say "wow, *now* I will finally try PostgreSQL"? It does not look like a major new feature to me, but rather (but not really) like a bug-fix or implementation detail. Unless I missed some huge performance gains due to it, in which case I think it should be worded differently. Michael -- Michael Banck Tel.: +49 (0) 2161 / 4643-171 credativ GmbH, HRB Mönchengladbach 12080 Hohenzollernstr. 133, 41061 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz
On Apr 22, 2013, at 4:08 AM, Michael Banck wrote: > Hi, > > Am Freitag, den 19.04.2013, 09:41 -0700 schrieb Josh Berkus: >> So, here's what we potentially have as "worth mentioning": >> >> * Views (updatable, matviews) >> * Federation (writeable fdw, pgsql_fdw) >> * LATERAL >> * regex indexes >> * No more SHMMAX/SHMMALL >> >> Is that everything? > > I am not sure "No more SHMMAX/SHMMALL" should be in the top 5 - it is > quite nice that DBAs do not have to fiddle with it anyway, but will it > make people say "wow, *now* I will finally try PostgreSQL"? It does not > look like a major new feature to me, but rather (but not really) like a > bug-fix or implementation detail. For developers who have had so much trouble installing / running Postgres on their local machines, it is a big deal. I don'tknow how many people I have had to help install Postgres on their local environments because it would not run rightout of the box. I think to go back to an earlier point that Andres made, the important thing about the beta is to list features that needtesting to see if they break in their development / semi-production environments and this is definitely one of thosefeatures. > Unless I missed some huge performance gains due to it, in which case I > think it should be worded differently. That I definitely agree with. Perhaps along the lines of "Removed need to tweak OS shared memory settings?" Jonathan
On 2013-04-22 10:25:34 -0400, Jonathan S. Katz wrote: > On Apr 22, 2013, at 4:08 AM, Michael Banck wrote: > > > Hi, > > > > Am Freitag, den 19.04.2013, 09:41 -0700 schrieb Josh Berkus: > >> So, here's what we potentially have as "worth mentioning": > >> > >> * Views (updatable, matviews) > >> * Federation (writeable fdw, pgsql_fdw) > >> * LATERAL > >> * regex indexes > >> * No more SHMMAX/SHMMALL > >> > >> Is that everything? > > > > I am not sure "No more SHMMAX/SHMMALL" should be in the top 5 - it is > > quite nice that DBAs do not have to fiddle with it anyway, but will it > > make people say "wow, *now* I will finally try PostgreSQL"? It does not > > look like a major new feature to me, but rather (but not really) like a > > bug-fix or implementation detail. > > For developers who have had so much trouble installing / running Postgres on their local machines, it is a big deal. Idon't know how many people I have had to help install Postgres on their local environments because it would not run rightout of the box. Yea. Besides not understanding pg_hba.conf its probably the most frequent problems I have seen with new (and not so new) users. > > Unless I missed some huge performance gains due to it, in which case I > > think it should be worded differently. > > That I definitely agree with. Perhaps along the lines of "Removed need to tweak OS shared memory settings?" I'd still formulate it as "reduce" as you still need to change variables if you have many clusters or higher max_connections. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Mon, Apr 22, 2013 at 04:27:52PM +0200, Andres Freund wrote: > On 2013-04-22 10:25:34 -0400, Jonathan S. Katz wrote: > > On Apr 22, 2013, at 4:08 AM, Michael Banck wrote: > > > > > Hi, > > > > > > Am Freitag, den 19.04.2013, 09:41 -0700 schrieb Josh Berkus: > > >> So, here's what we potentially have as "worth mentioning": > > >> > > >> * Views (updatable, matviews) > > >> * Federation (writeable fdw, pgsql_fdw) > > >> * LATERAL > > >> * regex indexes > > >> * No more SHMMAX/SHMMALL > > >> > > >> Is that everything? > > > > > > I am not sure "No more SHMMAX/SHMMALL" should be in the top 5 - it is > > > quite nice that DBAs do not have to fiddle with it anyway, but will it > > > make people say "wow, *now* I will finally try PostgreSQL"? It does not > > > look like a major new feature to me, but rather (but not really) like a > > > bug-fix or implementation detail. > > > > For developers who have had so much trouble installing / running Postgres on their local machines, it is a big deal. I don't know how many people I have had to help install Postgres on their local environments because it would not runright out of the box. > > Yea. Besides not understanding pg_hba.conf its probably the most > frequent problems I have seen with new (and not so new) users. > > > > Unless I missed some huge performance gains due to it, in which case I > > > think it should be worded differently. > > > > That I definitely agree with. Perhaps along the lines of "Removed need to tweak OS shared memory settings?" > > I'd still formulate it as "reduce" as you still need to change variables > if you have many clusters or higher max_connections. How about, "Removed the most common cases for tweaking OS shared memory settings" or something along that line? 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
* Josh Berkus: > PostgreSQL 9.3 Beta 1 is coming soon. As always, I could use your help > in coming up with some promotional text for the features it contains. > Here's the features I know of: The 9.3 release notes mention unix_socket_directories (plural), but I've already got that with 9.2 on Fedora. Or is this a Fedora thing?
On 4/25/13 6:51 PM, Florian Weimer wrote: > * Josh Berkus: > >> PostgreSQL 9.3 Beta 1 is coming soon. As always, I could use your help >> in coming up with some promotional text for the features it contains. >> Here's the features I know of: > > The 9.3 release notes mention unix_socket_directories (plural), but > I've already got that with 9.2 on Fedora. Or is this a Fedora thing? Yes.
On Fri, Apr 26, 2013 at 10:00 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
On 4/25/13 6:51 PM, Florian Weimer wrote:Yes.
> * Josh Berkus:
>
>> PostgreSQL 9.3 Beta 1 is coming soon. As always, I could use your help
>> in coming up with some promotional text for the features it contains.
>> Here's the features I know of:
>
> The 9.3 release notes mention unix_socket_directories (plural), but
> I've already got that with 9.2 on Fedora. Or is this a Fedora thing?
It is backported in all the RPMs I've seen. I believe it works on the 8.4 packaged in RHEL6 as well.
On 04/17/2013 10:21 AM, Thom Brown wrote: > On 17 April 2013 17:52, Josh Berkus <josh@agliodbs.com> wrote: >> All, >> >> Can someone come up with an example of how to use the new Regex indexing? > > There's an example in the dev docs: > http://www.postgresql.org/docs/devel/static/pgtrgm.html#AEN147751 Is regex indexing available only through Trigram, then? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com