Обсуждение: 9.0: Too many features. Help us choose!
Advocacy geeks, So, the issue I'm having with drafting a press release for 9.0 and editing the release notes is that we have too many features. We shouldn't include all in the major features section of the release notes, and we definitely can't include them all in the press release. In fact, in the press release, we can at best include 6 in addition to replication. So, to help decide what's a "major feature" for 9.0, I'd like people to fill out this web survey form: https://spreadsheets.google.com/viewform?formkey=dF9ZYmJoMGZGRGpxZ18xdG9OUGFqd3c6MQ Please help by seriously thinking about which features we should be really promoting for 9.0, and which we can leave for people to find in the release notes. Thanks! --Josh Berkus
All,
So I'm compiling this, and I was surprised to see that a lot of people
didn't consider the overhauled LISTEN/NOTIFY to be a major feature. For
those who voted "not a major feature", what was the reasoning? I'm curious.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On Tue, Jun 22, 2010 at 1:47 AM, Josh Berkus <josh@agliodbs.com> wrote: > All, > > So I'm compiling this, and I was surprised to see that a lot of people > didn't consider the overhauled LISTEN/NOTIFY to be a major feature. For > those who voted "not a major feature", what was the reasoning? I'm curious. I don't remember what I put in for that, but here's how I thought on a number of cases. The LISTEN/NOTIFY improvements are important to people who have been using postgresql for a long time, and use it in a way that's not all that common these days (look, ma, no ORM!). For an *outsider*, it's completely irrelevant - they didn't know there was a problem before (unlike vacuum which people have heard of forever, nobody has heard of issues with listen/notify), so it looks more like trying to push something because we didn't have enough relevant. The insiders will read the release notes and the details. The press release needs to capture new people. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > So I'm compiling this, and I was surprised to see that a lot of people > didn't consider the overhauled LISTEN/NOTIFY to be a major feature. For > those who voted "not a major feature", what was the reasoning? I'm curious. Because it acts exactly the same as before? From a user/usage perspective, nothing has changed, and most people don't bump up against the current limitations. I'm excited about it because Bucardo uses LISTEN/NOTIFY a *lot*, so this will be a win. Although the overhead of the current listen system still pales in comparison to the overhead of triggers. It will be nice to start using payloads as well. Those should be mentioned explicitly if they are not already. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 201006220907 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAkwgtcwACgkQvJuQZxSWSsh+RwCgggrpCeQ4Nb46coG8YVG4YOIj yzQAoK9hTo7oA7eAgk7WwtKcg56VkNRA =/4cn -----END PGP SIGNATURE-----
On Tue, Jun 22, 2010 at 09:55:50AM +0200, Magnus Hagander wrote: > On Tue, Jun 22, 2010 at 1:47 AM, Josh Berkus <josh@agliodbs.com> wrote: > > All, > > > > So I'm compiling this, and I was surprised to see that a lot of people > > didn't consider the overhauled LISTEN/NOTIFY to be a major feature. For > > those who voted "not a major feature", what was the reasoning? I'm curious. > > I don't remember what I put in for that, but here's how I thought on a > number of cases. The LISTEN/NOTIFY improvements are important to > people who have been using postgresql for a long time, and use it in a > way that's not all that common these days (look, ma, no ORM!). For an > *outsider*, it's completely irrelevant - they didn't know there was a > problem before (unlike vacuum which people have heard of forever, > nobody has heard of issues with listen/notify), so it looks more like > trying to push something because we didn't have enough relevant. > > The insiders will read the release notes and the details. The press > release needs to capture new people. In case this is a useful data point, that was exactly my reasoning as well. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com
Вложения
On 17 June 2010 02:01, Josh Berkus <josh@postgresql.org> wrote: > Advocacy geeks, > > So, the issue I'm having with drafting a press release for 9.0 and > editing the release notes is that we have too many features. We > shouldn't include all in the major features section of the release > notes, and we definitely can't include them all in the press release. > > In fact, in the press release, we can at best include 6 in addition to > replication. > > So, to help decide what's a "major feature" for 9.0, I'd like people to > fill out this web survey form: > > https://spreadsheets.google.com/viewform?formkey=dF9ZYmJoMGZGRGpxZ18xdG9OUGFqd3c6MQ > > Please help by seriously thinking about which features we should be > really promoting for 9.0, and which we can leave for people to find in > the release notes. Thanks! > Submitted my changes. I've focused mainly on what would most likely attract new users.
> On Tue, Jun 22, 2010 at 09:55:50AM +0200, Magnus Hagander wrote: >> On Tue, Jun 22, 2010 at 1:47 AM, Josh Berkus <josh@agliodbs.com> wrote: >>> All, >>> >>> So I'm compiling this, and I was surprised to see that a lot of people >>> didn't consider the overhauled LISTEN/NOTIFY to be a major feature. For >>> those who voted "not a major feature", what was the reasoning? I'm curious. >> >> I don't remember what I put in for that, but here's how I thought on a >> number of cases. The LISTEN/NOTIFY improvements are important to >> people who have been using postgresql for a long time, and use it in a >> way that's not all that common these days (look, ma, no ORM!). For an >> *outsider*, it's completely irrelevant - they didn't know there was a >> problem before (unlike vacuum which people have heard of forever, >> nobody has heard of issues with listen/notify), so it looks more like >> trying to push something because we didn't have enough relevant. >> >> The insiders will read the release notes and the details. The press >> release needs to capture new people. The one argument argument I would make towards mentioning LISTEN/NOTIFY is that there is a big push on the development sideto do more evented-programming. While it is not a new feature, I think you could attract a new set of developers byshowing what LISTEN/NOTIFY can do. One of the most requested features for the new version of Redis was a similar publish/subscribetype system, but of course in this case it was new. Now while I understand that this is not a new feature, a good way to capture some of the evented-programming interest isto make some follow-up blog posts after the announcement showing some examples of using LISTEN/NOTIFY and perhaps mentioningthe improvements. Jonathan
> I don't remember what I put in for that, but here's how I thought on a
> number of cases. The LISTEN/NOTIFY improvements are important to
> people who have been using postgresql for a long time, and use it in a
> way that's not all that common these days (look, ma, no ORM!). For an
> *outsider*, it's completely irrelevant - they didn't know there was a
> problem before (unlike vacuum which people have heard of forever,
> nobody has heard of issues with listen/notify), so it looks more like
> trying to push something because we didn't have enough relevant.
Yeah, I guess my perspective is different. From where I sit,
LISTEN/NOTIFY was a useless feature before: it didn't carry messages, it
had severe performance limitations. Suddenly, with the overhaul
, PostgreSQL has built-in transactional message queueing.
In other words, previously most people were unaware that LISTEN/NOTIFY
existed and I wouldn't have recommended it to them. Now it's a useful
tool which users can use to build new kinds of applications. HStore is
the same ... we had it in 8.4, but it wasn't useful. Now you can build
an application around it, as long as you don't use "=>".
Contrast this with the additional windowing functions, which received a
about an equal number of votes. In my experience, most of the public
doesn't even know what windowing functions are, and could care less that
we implemented 5 more of them. As far as the casual user is concerned,
we implemented windowing functions in 8.4 and we're done now.
From my perspective, the press release should focus on features which
answer the question "Why would I use PostgreSQL instead of another
databse?". I think that people here on the list agree in principle but
nevertheless tend to focus on features which support incremental
improvements of existing functionality over features which support
entirely new applications, if about half the votes are anything to go by.
Anyway, the voting did let me get a list of 5 "don't bother" features
and 5 "must have" features, which then means that the rest can be based
on PR discussion, and is what I expected. And let me settle the release
notes, where our space constraints are less.
The only question is ... should I broadcast this survey on -general to
try to get the perspective of more casual PostgreSQL users? Over half
of the current survey respondants called themselves "Experienced
PostgresQL Users" which is, I think, where part of the voting skew comes
from.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On 6/22/10 10:16 AM, Josh Berkus wrote:
> Suddenly, with the overhaul
> , PostgreSQL has built-in transactional message queueing.
built-in transactional event notifications. Sorry, point is the same
though.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On Tue, Jun 22, 2010 at 19:16, Josh Berkus <josh@agliodbs.com> wrote: > >> I don't remember what I put in for that, but here's how I thought on a >> number of cases. The LISTEN/NOTIFY improvements are important to >> people who have been using postgresql for a long time, and use it in a >> way that's not all that common these days (look, ma, no ORM!). For an >> *outsider*, it's completely irrelevant - they didn't know there was a >> problem before (unlike vacuum which people have heard of forever, >> nobody has heard of issues with listen/notify), so it looks more like >> trying to push something because we didn't have enough relevant. > > Yeah, I guess my perspective is different. From where I sit, LISTEN/NOTIFY > was a useless feature before: it didn't carry messages, it had severe > performance limitations. Suddenly, with the overhaul > , PostgreSQL has built-in transactional message queueing. Given the large number of installations I've come across that have been very happy with the previous LISTEN/NOTIFY, it's *far* from being useless in the versions we have out there today. There's certainly been room for improvement - which we now have - but calling it useless just tells me you're far disconnected from reality :P > In other words, previously most people were unaware that LISTEN/NOTIFY > existed and I wouldn't have recommended it to them. Now it's a useful tool > which users can use to build new kinds of applications. HStore is the same > ... we had it in 8.4, but it wasn't useful. Now you can build an > application around it, as long as you don't use "=>". > > Contrast this with the additional windowing functions, which received a > about an equal number of votes. In my experience, most of the public > doesn't even know what windowing functions are, and could care less that we > implemented 5 more of them. As far as the casual user is concerned, we > implemented windowing functions in 8.4 and we're done now. If they come from MySQL, they won't. If they come from one of the big databases, they will. The simple ability to do a moving average has a lot more users amongst my customers than the changes in LISTEN/NOTIFY, really. > From my perspective, the press release should focus on features which answer > the question "Why would I use PostgreSQL instead of another databse?". I > think that people here on the list agree in principle but nevertheless tend > to focus on features which support incremental improvements of existing > functionality over features which support entirely new applications, if > about half the votes are anything to go by. Uh, the LISTEN/NOTIFY change is as much an incremental improvement as the windowing functions, to keep up with your examples. You could do them both previously, but neither solution really scaled. > Anyway, the voting did let me get a list of 5 "don't bother" features and 5 > "must have" features, which then means that the rest can be based on PR > discussion, and is what I expected. And let me settle the release notes, > where our space constraints are less. > > The only question is ... should I broadcast this survey on -general to try > to get the perspective of more casual PostgreSQL users? Over half of the > current survey respondants called themselves "Experienced PostgresQL Users" > which is, I think, where part of the voting skew comes from. Probably not a bad idea. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
> Subject: Re: [pgsql-advocacy] 9.0: Too many features. Help us choose! Quick question. I just took a look at the original survey and, if I didn't know about PostgreSQL, I wouldn't know what half of those things are. Might it be a good idea to edit the original spreadsheet to include a short blurb about each feature and then further distribute the link to others, such as MySQL afficionados, mangers, etc. ? Perhaps make it more generic and ask a qusetion such as, "If you were evaluating a new database server for your project, which of the following features would compel you to evaluate the database further?" ...and then have the survey-taker report which database infrastructure they are most familiar with.
On Wed, 2010-06-16 at 18:01 -0700, Josh Berkus wrote: > So, to help decide what's a "major feature" for 9.0, I'd like people to > fill out this web survey form: > > https://spreadsheets.google.com/viewform?formkey=dF9ZYmJoMGZGRGpxZ18xdG9OUGFqd3c6MQ GAH where is my eye bleach. > > Please help by seriously thinking about which features we should be > really promoting for 9.0, and which we can leave for people to find in > the release notes. Thanks! > > --Josh Berkus > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering
>
"If you were evaluating
> a new database server for your project, which of the following features
> would compel you to evaluate the database further?" ...and then have
> the survey-taker report which database infrastructure they are most
> familiar with.
I'd need better survey technology to do that, unfortunately.
Suggestions? Google is limited on question length, and SurveyMonkey is
not useful unless you shell out $$$.
But, point taken. Absent longer descriptions, surveying -general isn't
going to do much good. Of the 4 "application developers" who answered
the survey, half their answers were "I don't know what this feature is".
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
> Given the large number of installations I've come across that have
> been very happy with the previous LISTEN/NOTIFY, it's *far* from being
> useless in the versions we have out there today. There's certainly
> been room for improvement - which we now have - but calling it useless
> just tells me you're far disconnected from reality :P
Ah. I'd had a completely different experience; tried to use
listen/notify for two different projects and had to give up and use
something else.
> Uh, the LISTEN/NOTIFY change is as much an incremental improvement as
> the windowing functions, to keep up with your examples. You could do
> them both previously, but neither solution really scaled.
Yeah, I guess I'm a bit focused on the appdev crowd these days in
exclusion to the big database people. Comes of my current travel and
clientele.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
> I'd need better survey technology to do that, unfortunately. > Suggestions? Google is limited on question length, and SurveyMonkey is > not useful unless you shell out $$$. If you'd like, I can toss a djsngo-survey up on one of my sites, with the caveat that I've never used django-survey before. ;) http://code.google.com/p/django-survey/ -- ----- http://www.globalherald.net/jb01 GlobalHerald.NET, the Smarter Social Network! (tm)
On Tuesday 22. June 2010 19.44.51 Joshua D. Drake wrote: > On Wed, 2010-06-16 at 18:01 -0700, Josh Berkus wrote: > > So, to help decide what's a "major feature" for 9.0, I'd like people to > > fill out this web survey form: > > > > https://spreadsheets.google.com/viewform?formkey=dF9ZYmJoMGZGRGpxZ18xdG9OUGFqd3c6MQ > > GAH where is my eye bleach. Apart from the horrible color scheme, I have to confess that I don't understand most of the questions. I'd like to describe myself as an "Experienced PostgreSQL user" as I've been fiddling around with it since 7.4, but this questionnaire might as well have been written in Russian wrt my level of understanding. Those features that I do understand, such as "Windows 64-bit support", "PL/Perl and PL/Python improvements" or "Automatic Join Removal for optimizing ORM-generated queries" are of no importance to me. And an item such as "Red- Black Trees for improved GIN index updates " is just plain humiliating. How many persons on this planet knows what that is? The item with the highest cool factor for me is probably the "Anonymous procedure blocks with the DO statement" which I'm looking forward to try out. regards, -- Leif Biberg Kristensen http://solumslekt.org/blog/
On 6/22/10 1:52 PM, Joshua Kramer wrote:
>
>> I'd need better survey technology to do that, unfortunately.
>> Suggestions? Google is limited on question length, and SurveyMonkey is
>> not useful unless you shell out $$$.
>
> If you'd like, I can toss a djsngo-survey up on one of my sites, with
> the caveat that I've never used django-survey before. ;)
If you have the time, please do. Per Simon, we want to do a follow-up
survey after the release as well.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On Wed, 2010-06-16 at 18:01 -0700, Josh Berkus wrote: > So, to help decide what's a "major feature" for 9.0, I'd like people to > fill out this web survey form: > > https://spreadsheets.google.com/viewform?formkey=dF9ZYmJoMGZGRGpxZ18xdG9OUGFqd3c6MQ GAH where is my eye bleach. > > Please help by seriously thinking about which features we should be > really promoting for 9.0, and which we can leave for people to find in > the release notes. Thanks! > > --Josh Berkus > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering
Leif Biberg Kristensen wrote: > And an item such as "Red-Black Trees for improved GIN index updates " is just plain humiliating. How > many persons on this planet knows what that is? > A Red-Black tree is an efficient way to store and manipulate the sorts of data trees common to database index implementations: http://en.wikipedia.org/wiki/Red-black_tree ; they're one of the standard things taught in computer science classes. GIN is a special type of PostgreSQL index: http://www.postgresql.org/docs/current/static/gin-intro.html that is useful for purposes such as full-text search: http://www.postgresql.org/docs/current/static/textsearch-indexes.html Put the two together, and you have improved GIN index updates, relative to the less optimized tree structure used in earlier versions. As for how many people understood that from the short description, I'd expect that anyone with a formal CS background who also works on PostgreSQL would, guessing at least a few dozen developers floating around the community match that combination. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us
On 06/23/2010 07:39 AM, Sean Crowley wrote:
> Hi Josh,
>
> Haven't had a chance to read through all of the comments here (I'm
> covering 3 trade shows this week, so its a little hectic), but when you
> think that you have narrowed down the list of key features to use,
> please send me a cleaned up version of the release and I can have our PR
> team do some wordsmithing on it.
Well, I'd be more interested in having you and Rob give advice on the
central themes of the release. How I have it structured now is:
Built-in Replication
Truckload of features
Enterprise database features
Exotic/cutting edge features
I'd like to see if you feel that that structure makes sense. As I've
said to Rob, I don't think that the specific features are as important
as the fact that there are so many of them. No matter what we list,
we'll be leaving just as many out.
Sean, I'm also hunting for companies or institutions who are excited
about the 9.0 release and are willing to be quoted. Know any?
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com