Re: [HACKERS] 8.2 features status
Joshua D. Drake wrote: Or better yet, if editing the TODO is more accessible then we're not dependent on one person to maintain it. To be fair, Bruce has offered to allow that to happen even on his home machine (Bruce that is a bad idea btw) and ANYONE can submit a patch. It may not be a web interface that people could log into but it is entirely possible to contribute back with it. Er, that offer was not to all and sundry as I understood it, but for one or two people. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.2 features status
Jim C. Nasby wrote: On Wed, Aug 09, 2006 at 08:21:41AM -0700, Joshua D. Drake wrote: From Bruce's perspective this actually doesn't add too much to the workload. Generate the link, possibly paste some archive urls into the wiki and then someone can come behind and clean up. Or better yet, if editing the TODO is more accessible then we're not dependent on one person to maintain it. I have offered shell accounts to people, or perhaps we could push the entire TODO list up to a web site, though I am afraid it would be more complicated to update than it is now. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 8.2 features status
Joshua D. Drake wrote: We now have URLs on the TODO list to the archives, and the next FAQ item is: H3 id=item1.41.4) What do I do after choosing an item to work on?/H3 PSend an email to pgsql-hackers with a proposal for what you want to do (assuming your contribution is not trivial). Working in so it is clear what we want people to do. what we want my be part of the problem :) It would also be useful to have possible dependencies. I recently saw a patch come across from Sun, that Tom commented on, something about increase the size of some value to 64bit. I don't recall exactly. I am keeping URLs in the TODO list. Why don't people submit improvements to the TODO list, rather than adding more complexity by making a separate wiki for every TODO item? If no one updates the TODO item, what makes you think they are going to do somethin in a wiki? Do you want a todo list with 4 paragraphs (minimum) for each todo item? The requirements of the item often change dramatically over time, so who is going to write paragraphs for a single item, especially if it will need updating. I think the big conclusion we made long ago is that We are never going to have enough detail anywhere that someone is going to be able to work on an item without asking the community. I don't think anyone is expecting that. I think that what we are expecting is that they can ask knowledgeable questions. Would you prefer: Hi, I am a C developer, PostgreSQL Rocks... I want to implement Enums.. Or: Hi, I am a C developer, PostgreSQL Rocks... I would like to take the Enums todo. Here are my specific questions regarding your feature requirements at URL --- Well, few have shown any interest in improving the TODO list, so who is going to be motivated to do even more than we have now? -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
Joshua D. Drake wrote: Jim C. Nasby wrote: On Wed, Aug 09, 2006 at 08:21:41AM -0700, Joshua D. Drake wrote: From Bruce's perspective this actually doesn't add too much to the workload. Generate the link, possibly paste some archive urls into the wiki and then someone can come behind and clean up. Or better yet, if editing the TODO is more accessible then we're not dependent on one person to maintain it. To be fair, Bruce has offered to allow that to happen even on his home machine (Bruce that is a bad idea btw) and ANYONE can submit a patch. It Probably, but that's OK. may not be a web interface that people could log into but it is entirely possible to contribute back with it. It is very easy to update because it is a simple text file. The HTML is added automatically. Hard to see how it could be easier than that. I can even pull a TODO file from some server location and update from that if you don't want to ssh in but want to put your version at some URL. Or update update the CVS version and email it to me. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 8.2 features status
Jim C. Nasby wrote: On Tue, Aug 08, 2006 at 10:31:00PM -0400, Bruce Momjian wrote: bruce wrote: bruce wrote: OK, seems this should be a separate application, not done in the TODO list, and I am not willing to take on that additional workload. Let me add that anyone who has CVS commit access or wants to submit TODO patches can keep the TODO updated in this way. I can also give someone ssh access to my server with the ability to modify only the TODO list. I've never submitted patches for the TODO because it seems pretty silly to go through that much work just to add one line to a file, but being able to change it directly would be a good compromise. I'd be happy to help. Something else that bugs me about the current TODO process is there's a lot of ideas that get brought up but never make it on there. Certainly a lot of them aren't worth putting on there, but there's plenty of items that get left on the floor. It would be nice if there was a better way to deal with these ideas. I have to be selective because having items we aren't sure we want on there isn't helpful. One possibility: have a 'holding area' (perhaps on a Wiki) where users could add use-cases for these ideas. If there's 'enough demand' (however one defines that), they get promoted to the TODO. Note that this is something geared towards users... things that are obviously useful to -hackers tend to get on the list. Yea, that would be interesting, like a pending TODO item list. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
It would also be useful to have possible dependencies. I recently saw a patch come across from Sun, that Tom commented on, something about increase the size of some value to 64bit. I don't recall exactly. I am keeping URLs in the TODO list. Why don't people submit improvements to the TODO list, rather than adding more complexity by making a separate wiki for every TODO item? If no one updates the TODO item, what makes you think they are going to do somethin in a wiki? Do you want a todo list with 4 paragraphs (minimum) for each todo item? The requirements of the item often change dramatically over time, so who is going to write paragraphs for a single item, especially if it will need updating. O.k. maybe the other people haven't written it loud enough :). That is the whole point of a WIKI. :) Or: Hi, I am a C developer, PostgreSQL Rocks... I would like to take the Enums todo. Here are my specific questions regarding your feature requirements at URL --- Well, few have shown any interest in improving the TODO list, so who is going to be motivated to do even more than we have now? Bruce you have at least a dozen people right now that are willing to help. :) . I know for a fact that Andrew, Myself, Devrim and Darcy would all be willing to help. I would throw Alvaro in there too but he is probably the busiest of us all and would likely kill me ;) I bet Jim would also be willing to help. Between you, and Tom and Peter and Neil, and Alvaro we have all the engineer brains to help back us up. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2 features status
Andrew Dunstan wrote: Bruce Momjian wrote: I am keeping URLs in the TODO list. Why don't people submit improvements to the TODO list, rather than adding more complexity by making a separate wiki for every TODO item? If no one updates the TODO item, what makes you think they are going to do somethin in a wiki? You can update a wiki instantly. Unless you are a committer, updating the TODO list involves sending in a patch. It should be added that the idea that the TODO list has much authority has been decried in the past. True, it is my attempt at a TODO, and people do ask for adjustments. I think the big conclusion we made long ago is that We are never going to have enough detail anywhere that someone is going to be able to work on an item without asking the community. Wikis take a tiny bit of getting used to. But they are extremely useful - they can be used like a kind of online notebook. I find it much easier to make progress notes, reminders, etc in a wiki than in a notebook that I forget to take with me half the time. And they are thus also a great place to record progress. Until you have used this, it seems strange. After you start it doesn't ;-) Sure, but with openness comes cruft, which can be a problem too. Do we want everyone's idea of a useful feature listed? I don't. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
Andrew Dunstan wrote: Joshua D. Drake wrote: Or better yet, if editing the TODO is more accessible then we're not dependent on one person to maintain it. To be fair, Bruce has offered to allow that to happen even on his home machine (Bruce that is a bad idea btw) and ANYONE can submit a patch. It may not be a web interface that people could log into but it is entirely possible to contribute back with it. Er, that offer was not to all and sundry as I understood it, but for one or two people. Well, either people post the changes publically or I trust a few people. I don't trust everyone or the TODO becomes a dumping ground, which I am afraid might happen with a wiki that anyone can update. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
Until you have used this, it seems strange. After you start it doesn't ;-) Sure, but with openness comes cruft, which can be a problem too. Do we want everyone's idea of a useful feature listed? I don't. Why not as long as we have someone who can actually make approved todos versus wishlist type stuff. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.2 features status
Joshua D. Drake wrote: Hi, I am a C developer, PostgreSQL Rocks... I would like to take the Enums todo. Here are my specific questions regarding your feature requirements at URL --- Well, few have shown any interest in improving the TODO list, so who is going to be motivated to do even more than we have now? Bruce you have at least a dozen people right now that are willing to help. :) . I know for a fact that Andrew, Myself, Devrim and Darcy would all be willing to help. I would throw Alvaro in there too but he is probably the busiest of us all and would likely kill me ;) I bet Jim would also be willing to help. Between you, and Tom and Peter and Neil, and Alvaro we have all the engineer brains to help back us up. OK, so how do you want to help is the question. Having received almost zero ideas for the current TODO list from any of those people, I am waiting for an answer. ;-) -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.2 features status
Joshua D. Drake wrote: Until you have used this, it seems strange. After you start it doesn't ;-) Sure, but with openness comes cruft, which can be a problem too. Do we want everyone's idea of a useful feature listed? I don't. Why not as long as we have someone who can actually make approved todos versus wishlist type stuff. So you want a wish-list wiki? Great idea, I can link to it from the TODO list. Is that all people want? -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 8.2 features status
Bruce Momjian wrote: Joshua D. Drake wrote: Until you have used this, it seems strange. After you start it doesn't ;-) Sure, but with openness comes cruft, which can be a problem too. Do we want everyone's idea of a useful feature listed? I don't. Why not as long as we have someone who can actually make approved todos versus wishlist type stuff. So you want a wish-list wiki? Great idea, I can link to it from the TODO list. Is that all people want? Do you miss my point (not being sarcastic) about having: 1. Better descriptions about the todo/feature? E.g; feature specification 2. The ability to categorize todo items 3. Heck *your portion* of the TODO would be easily satisfied by having a single line with a link that points to the specific wiki page. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
Joshua D. Drake wrote: Bruce Momjian wrote: Joshua D. Drake wrote: Until you have used this, it seems strange. After you start it doesn't ;-) Sure, but with openness comes cruft, which can be a problem too. Do we want everyone's idea of a useful feature listed? I don't. Why not as long as we have someone who can actually make approved todos versus wishlist type stuff. So you want a wish-list wiki? Great idea, I can link to it from the TODO list. Is that all people want? Do you miss my point (not being sarcastic) about having: 1. Better descriptions about the todo/feature? E.g; feature specification I am not sure there is enough churn of TODO items to make larger descriptions worth it. As it is, I have to link to new URLs as the TODO item is clarified. 2. The ability to categorize todo items Categorize how? 3. Heck *your portion* of the TODO would be easily satisfied by having a single line with a link that points to the specific wiki page. But who is going to do that if no one has done anything in the past for the TODO list. I keep asking that. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
1. Better descriptions about the todo/feature? E.g; feature specification I am not sure there is enough churn of TODO items to make larger descriptions worth it. As it is, I have to link to new URLs as the TODO item is clarified. Are you kidding? Did you see the discussion just on the todo item that I tried to do? 2. The ability to categorize todo items Categorize how? 3. Heck *your portion* of the TODO would be easily satisfied by having a single line with a link that points to the specific wiki page. But who is going to do that if no one has done anything in the past for the TODO list. I keep asking that. I believe that Andrew and I as well as a few others would be willing to do it. Of course I am speaking for Andrew here and I hope he agrees. I also know that Devrim would be more then happy to help out. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.2 features status
Joshua D. Drake wrote: 1. Better descriptions about the todo/feature? E.g; feature specification I am not sure there is enough churn of TODO items to make larger descriptions worth it. As it is, I have to link to new URLs as the TODO item is clarified. Are you kidding? Did you see the discussion just on the todo item that I tried to do? Right, but the problem was a poor TODO item that needed improvement. I don't think I even remembered the reason for the item, but over time the requirement for the item had changed, I think, or it wasn't clear at the time it was proposed. 2. The ability to categorize todo items Categorize how? 3. Heck *your portion* of the TODO would be easily satisfied by having a single line with a link that points to the specific wiki page. But who is going to do that if no one has done anything in the past for the TODO list. I keep asking that. I believe that Andrew and I as well as a few others would be willing to do it. Of course I am speaking for Andrew here and I hope he agrees. I also know that Devrim would be more then happy to help out. OK, so what do you want to do? -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 8.2 features status
Heikki Linnakangas wrote: Bruce Momjian wrote: I am keeping URLs in the TODO list. Why don't people submit improvements to the TODO list, rather than adding more complexity by making a separate wiki for every TODO item? If no one updates the TODO item, what makes you think they are going to do somethin in a wiki? Well, since you asked, here's an patch to add an archive link for a todo item that I'm working on. (I'll send a separate mail about that shortly). *** TODO9 Aug 2006 02:48:10 -1.1942 --- TODO9 Aug 2006 16:20:21 - *** *** 583,588 --- 583,590 store heap rows in hashed groups, perhaps using a user-supplied hash function. + http://archives.postgresql.org/pgsql-performance/2004-08/msg00349.php + o %Add default clustering to system tables To do this, determine the ideal cluster index for each system Added. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
3. Heck *your portion* of the TODO would be easily satisfied by having a single line with a link that points to the specific wiki page. But who is going to do that if no one has done anything in the past for the TODO list. I keep asking that. I believe that Andrew and I as well as a few others would be willing to do it. Of course I am speaking for Andrew here and I hope he agrees. I also know that Devrim would be more then happy to help out. OK, so what do you want to do? Oh, sure makes us deliver on our arguments. How very un open source of you :).. Let me get with andrew and I will post back and actual solidified idea. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
Bruce Momjian wrote: I am keeping URLs in the TODO list. Why don't people submit improvements to the TODO list, rather than adding more complexity by making a separate wiki for every TODO item? If no one updates the TODO item, what makes you think they are going to do somethin in a wiki? Well, since you asked, here's an patch to add an archive link for a todo item that I'm working on. (I'll send a separate mail about that shortly). *** TODO9 Aug 2006 02:48:10 -1.1942 --- TODO9 Aug 2006 16:20:21 - *** *** 583,588 --- 583,590 store heap rows in hashed groups, perhaps using a user-supplied hash function. + http://archives.postgresql.org/pgsql-performance/2004-08/msg00349.php + o %Add default clustering to system tables To do this, determine the ideal cluster index for each system Fortunately, when you pick up some thread from the mailing list and make a todo item, you post a reply to that thread with the wording. That makes it easy to find archive links for older todo items, just search the archive for the exact phrase that's on the todo item. For example, I found that thread by searching for Automatically maintain clustering on a table. It would be useful to go through all the todo items that don't have a URL, search for the discussions in the archives that inspired them, and add links to them. I think the big conclusion we made long ago is that We are never going to have enough detail anywhere that someone is going to be able to work on an item without asking the community. Agreed. Note also that the community might not agree on the way TODO item should be implemented, or even on if a feature is necessary. It's more useful to have a reference to all opinions and ideas relevant to the item, than try prescribe a specific design in the TODO description. BTW: Just to let people know, I've just moved to UK and joined EnterpriseDB, so I'm going to be a lot more active with PostgreSQL in the future. - Heikki ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.2 features status
OK, so what do you want to do? Oh, sure makes us deliver on our arguments. How very un open source of you :).. Let me get with andrew and I will post back and actual solidified idea. Andrew and I are tabling this until I get back from LinuxWorld. We will be discussing potential ideas to present via email during that week. Joshua D. Drake Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 8.2 features status
Joshua D. Drake [EMAIL PROTECTED] writes: It would also be useful to have possible dependencies. I recently saw a patch come across from Sun, that Tom commented on, something about increase the size of some value to 64bit. I don't recall exactly. Tom's comments although valid (as usual :)) were that the person missed a bunch of stuff having to do with the planner. Some of us may think... well of course that is obvious... Well either the Sun guy was just lazy, or it isn't obvious. I prefer to think it is not obvious. IIRC the problem with that patch was basically that the guy had failed to search all of the source code for references to the struct he wanted to modify. This isn't really the fault of the TODO list. It could be (probably already is) a hint in the developer's FAQ ... but I can't see putting that sort of generic how-to-develop-a-good-patch kind of info into every TODO item. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 8.2 features status
I am actually hoping that jabber.postgresql.org would help that in the long run. Jabber's ok, but why not go with SILC instead? ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2 features status
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: It would also be useful to have possible dependencies. I recently saw a patch come across from Sun, that Tom commented on, something about increase the size of some value to 64bit. I don't recall exactly. Tom's comments although valid (as usual :)) were that the person missed a bunch of stuff having to do with the planner. Some of us may think... well of course that is obvious... Well either the Sun guy was just lazy, or it isn't obvious. I prefer to think it is not obvious. IIRC the problem with that patch was basically that the guy had failed to search all of the source code for references to the struct he wanted to modify. This isn't really the fault of the TODO list. It could be (probably already is) a hint in the developer's FAQ ... but I can't see putting that sort of generic how-to-develop-a-good-patch kind of info into every TODO item. I entirely assumed that your references were correct. It was just the only example that I could think up off the top of my head. I was more trying to display a good use of possible dependecies. SIncerely, Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
Andrew Hammond wrote: I am actually hoping that jabber.postgresql.org would help that in the long run. Jabber's ok, but why not go with SILC instead? Because everything supports jabber, I only know of SILC and gaim that support SILC :). Also Jabber is pretty much an accepted standard at this point and if we ever decide to open the server it would be nice to talk to gmail etc... Sincerely, Joshua D. Drake ---(end of broadcast)--- TIP 6: explain analyze is your friend -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.2 features status
On Wed, 2006-08-09 at 12:15 -0400, Bruce Momjian wrote: Well, either people post the changes publically or I trust a few people. I don't trust everyone or the TODO becomes a dumping ground, which I am afraid might happen with a wiki that anyone can update. I think that's preventable, especially if we require logins to edit the wiki: while people are free to add content, others can clean up new content and remove dubious additions. Besides, I think the TODO list is speculative by nature: there are plenty of vague or half-baked ideas on the current TODO list, for example. For those who haven't seen it, I think the GCC Wiki is a good model: http://gcc.gnu.org/wiki Personally I'd like to see us move toward maintaining the TODO list and similar developer-oriented information primarily on a wiki. -Neil ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
On Wed, Aug 09, 2006 at 01:56:42PM -0700, Neil Conway wrote: On Wed, 2006-08-09 at 12:15 -0400, Bruce Momjian wrote: Well, either people post the changes publically or I trust a few people. I don't trust everyone or the TODO becomes a dumping ground, which I am afraid might happen with a wiki that anyone can update. I think that's preventable, especially if we require logins to edit the wiki: while people are free to add content, others can clean up new content and remove dubious additions. Besides, I think the TODO list is speculative by nature: there are plenty of vague or half-baked ideas on the current TODO list, for example. For those who haven't seen it, I think the GCC Wiki is a good model: http://gcc.gnu.org/wiki Personally I'd like to see us move toward maintaining the TODO list and similar developer-oriented information primarily on a wiki. Another possibility for questionabl TODO items is to allow users to vote on them. Bugzilla (just as an example) allows users to vote on bugs, but they're only given a limited number of votes, so they have to decide what's most important to them. There's also the idea of TODO purgatory that I mentioned earlier. The issue I'm thinking of here is that there are things that would be very beneficial for users to have but that much of -hackers won't care about. Right now, we don't do a very good job of identifying those things (IMHO). -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
On Wednesday 09 August 2006 12:12, Bruce Momjian wrote:
One possibility: have a 'holding area' (perhaps on a Wiki) where users
could add use-cases for these ideas. If there's 'enough demand' (however
one defines that), they get promoted to the TODO. Note that this is
something geared towards users... things that are obviously useful to
-hackers tend to get on the list.
Yea, that would be interesting, like a pending TODO item list.
Wouldn't a thread reply saying something like Bruce, can we add this as a
TODO with the following wording: blah blah blah likely suffice?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
Robert Treat wrote: On Wednesday 09 August 2006 12:12, Bruce Momjian wrote: One possibility: have a 'holding area' (perhaps on a Wiki) where users could add use-cases for these ideas. If there's 'enough demand' (however one defines that), they get promoted to the TODO. Note that this is something geared towards users... things that are obviously useful to -hackers tend to get on the list. Yea, that would be interesting, like a pending TODO item list. Wouldn't a thread reply saying something like Bruce, can we add this as a TODO with the following wording: blah blah blah likely suffice? Yeah - and/or a patch to TODO or the relevant TODO.detail (I can't see why that is hard or onerous). Plus it is seen by a wide audience, some of whom might not be tracking any wiki (very likely if there end up being several wiki's) On that note, one nice feature of the current setup, is that the only place you need to look is the TODO, which then (hopefully) points you to a detail or url for more info. To have to check the TODO *and* the wiki is just one more thing to forget IMHO. Cheers Mark ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
On Wed, 9 Aug 2006, Dave Page wrote: Marc was setting up developer.postgresql.org as a developers wiki btw... Dunno what happened to that. Marc? Two words: House Hunting ... I have to download the stuff from pgFoundry tomorrow night, already have the database server running locally ... will post something to -www as soon as I have something up and running ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
Mark Kirkwood [EMAIL PROTECTED] writes: Robert Treat wrote: Wouldn't a thread reply saying something like Bruce, can we add this as a TODO with the following wording: blah blah blah likely suffice? That's pretty much how it's done now ... Yeah - and/or a patch to TODO or the relevant TODO.detail (I can't see why that is hard or onerous). Plus it is seen by a wide audience, some of whom might not be tracking any wiki (very likely if there end up being several wiki's) Yeah, the main problem I have with TODO-on-a-wiki is the question of quality control. I've been heard to complain that the TODO list consists of everything Bruce thinks is a good idea, but for the most part things don't get onto TODO without some rough consensus on the mailing lists --- at least about the nature of the problem, if not the exact shape of the solution. I'm worried about a wiki having pages that have not been peer-reviewed at all. In some respects that wouldn't matter, but what of our hypothetical newbie developer coming along and taking entries at face value? If you don't know the project well enough to recognize bogus entries, you could still end up wasting your time on silly ideas that will get rejected once seen by a wider audience. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.2 features status
Bruce Momjian wrote: I know about the same as the community members who pay attention to postings. What I do is to act on that information by contacting developers and asking them to complete their work for feature freeze. Many of my conversations are not appropriate for the public, which is why it is done privately. In fact, the feedback I have gotten from some community members that have heard a little of the discussions I have had with developers is that I am too forceful. I know that doesn't match my often non-critical or even lax handling of things, but I take my community responsibility seriously, and if someone has stated they are working on an item, I expect them to take that pledge seriously as well. Is that a response from other developers, or from those you have pressed a bit? Perhaps the fact that the process is so very informal has led people to false expectations anyway. Maybe if we were quite up front about it people would not get upset. If you say you will work on feature X, expect an occasional ping from someone asking about progress. As far as people always asking for better tracking, they used to always ask for a roadmap, and when we stated we couldn't because we have no control over developers, they pointed to Mozilla, which had a roadmap at the time (but we know what happened to them.) This seems to me to be a case of the well known fallacy post hoc ergo propter hoc. The fact that mozilla had some less than good results does not mean that everything they did was wrong. In the case of recursive queries, I did more than might have even been polite to try to get the developer to complete it. I don't see how changing our system is going to improve it. If you want to change the system, find a system that would have actually done better than what we have in place. Or try a new system, and I will keep doing what I do, and we can see which system works best. Excellent idea. We don't have to have a one size fits all set of procedures anyway - in fact I think it might be a mistake. Maybe we should select a few major features that people will work on for 8.3 and try a different model. We could then assess things around this time next cycle. cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
Andrew Dunstan wrote: Bruce Momjian wrote: I know about the same as the community members who pay attention to postings. What I do is to act on that information by contacting developers and asking them to complete their work for feature freeze. Many of my conversations are not appropriate for the public, which is why it is done privately. In fact, the feedback I have gotten from some community members that have heard a little of the discussions I have had with developers is that I am too forceful. I know that doesn't match my often non-critical or even lax handling of things, but I take my community responsibility seriously, and if someone has stated they are working on an item, I expect them to take that pledge seriously as well. Is that a response from other developers, or from those you have pressed a bit? Perhaps the fact that the process is so very informal has led From other developers, not those I have pressed. people to false expectations anyway. Maybe if we were quite up front about it people would not get upset. If you say you will work on feature X, expect an occasional ping from someone asking about progress. As far as people always asking for better tracking, they used to always ask for a roadmap, and when we stated we couldn't because we have no control over developers, they pointed to Mozilla, which had a roadmap at the time (but we know what happened to them.) This seems to me to be a case of the well known fallacy post hoc ergo propter hoc. The fact that mozilla had some less than good results does not mean that everything they did was wrong. My point is that we knew the idea was useless for us at the time, even though people asked for it over and over again. In the case of recursive queries, I did more than might have even been polite to try to get the developer to complete it. I don't see how changing our system is going to improve it. If you want to change the system, find a system that would have actually done better than what we have in place. Or try a new system, and I will keep doing what I do, and we can see which system works best. Excellent idea. We don't have to have a one size fits all set of procedures anyway - in fact I think it might be a mistake. Maybe we should select a few major features that people will work on for 8.3 and try a different model. We could then assess things around this time next cycle. My big point is that we should choose a system that would have had a better chance of completing features than what we have used in the past, and no one has suggested one. It is just like the bug tracker issue. Many think we need a bugtracker, but when I ask to see a project that has one that is better than what we have now, no one responds. Again, the same criteria should be applied to this issue. If people want to do something different with no objective hope it will be better, feel free to go ahead and do it, but I can't get excited about spending time on it. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.2 features status
Bruce Momjian wrote: Or try a new system, and I will keep doing what I do, and we can see which system works best. Excellent idea. We don't have to have a one size fits all set of procedures anyway - in fact I think it might be a mistake. Maybe we should select a few major features that people will work on for 8.3 and try a different model. We could then assess things around this time next cycle. My big point is that we should choose a system that would have had a better chance of completing features than what we have used in the past, and no one has suggested one. It is just like the bug tracker issue. Many think we need a bugtracker, but when I ask to see a project that has one that is better than what we have now, no one responds. Again, the same criteria should be applied to this issue. If people want to do something different with no objective hope it will be better, feel free to go ahead and do it, but I can't get excited about spending time on it. I give up. You say try something else and we'll see what works best. I respond great idea.. Then you say but it won't work anyway. Is it any wonder people get frustrated? Why give the illusion of an open mind when you have already made up your mind? cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 8.2 features status
Andrew Dunstan wrote: My big point is that we should choose a system that would have had a better chance of completing features than what we have used in the past, and no one has suggested one. It is just like the bug tracker issue. Many think we need a bugtracker, but when I ask to see a project that has one that is better than what we have now, no one responds. Again, the same criteria should be applied to this issue. If people want to do something different with no objective hope it will be better, feel free to go ahead and do it, but I can't get excited about spending time on it. I give up. You say try something else and we'll see what works best. I respond great idea.. Then you say but it won't work anyway. Is it any wonder people get frustrated? Why give the illusion of an open mind when you have already made up your mind? I am saying other people can try a new system, but I don't have time to try something different when no evidence has been given that it is better (just different). Or try a new system, and I will keep doing what I do, and we can see which system works best. I realized when I said, we can try that I was being inconsistent, but I was just saying that if others want to try something, go ahead. I personally don't see how it will improve things, but if others want to spend time on it, they are welcome to do that. What I am not willing to do is to abandon a system that works for one that doesn't have evidence it is an improvement, and I don't want to spend time on a new system just for the sake of trying to do two systems at once. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2 features status
Bruce Momjian wrote: I am saying other people can try a new system, but I don't have time to try something different when no evidence has been given that it is better (just different). Ok, not sure if I am in a position to call shots like I am about to, but here it goes: Could everybody who is willing to invest time setting up an alternative contact me so that we can maybe get together in IRC to talk things through and come up with a solid game plan? Maybe with such a plan we can also get Bruce to atleast give us infrequent, even very raw, brain dumps so that we do not face developers with all too much redundant information seeking. regards, Lukas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.2 features status
For example: Make postmater and postgres options distinct so the postmaster -o option is no longer needed | PeterE | Confirmed for 8.2 | 07/20/06 We could do that, but once an item is done I don't see the point in having the date and person's name. You are right that is clearly a different purpose from the TODO list, and if someone wants to track that, it might help things. The idea of the above is not to track when it is done. THe confirmed is to track that development is taking place and that we have confirmed from the developer that they think it will be done for 8.2. It is something that in theory would update throughout the cycle 3 or 4 times. You could even have: Make postmater and postgres options distinct so the postmaster -o option is no longer needed | PeterE | Confirmed for 8.2 | 04/20/06 Make postmater and postgres options distinct so the postmaster -o option is no longer needed | PeterE | Trouble encountered | 06/20/06 Make postmater and postgres options distinct so the postmaster -o option is no longer needed | PeterE | Asks for help | 08/20/06 Make postmater and postgres options distinct so the postmaster -o option is no longer needed | Alvaro | Confirmed | 09/20/06 Notice the sequence of events. I am not saying the specific statuses are the way to go but it would give a simple way to keep tabs on things without having to create a whole new ball of yarn. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
Joshua D. Drake wrote: For example: Make postmater and postgres options distinct so the postmaster -o option is no longer needed | PeterE | Confirmed for 8.2 | 07/20/06 We could do that, but once an item is done I don't see the point in having the date and person's name. You are right that is clearly a different purpose from the TODO list, and if someone wants to track that, it might help things. The idea of the above is not to track when it is done. THe confirmed is to track that development is taking place and that we have confirmed from the developer that they think it will be done for 8.2. Oh, confirmed confused me. Maybe anticipated or planned for 8.2. It is something that in theory would update throughout the cycle 3 or 4 times. You could even have: Make postmater and postgres options distinct so the postmaster -o option is no longer needed | PeterE | Confirmed for 8.2 | 04/20/06 Make postmater and postgres options distinct so the postmaster -o option is no longer needed | PeterE | Trouble encountered | 06/20/06 Make postmater and postgres options distinct so the postmaster -o option is no longer needed | PeterE | Asks for help | 08/20/06 Make postmater and postgres options distinct so the postmaster -o option is no longer needed | Alvaro | Confirmed | 09/20/06 Notice the sequence of events. I am not saying the specific statuses are the way to go but it would give a simple way to keep tabs on things without having to create a whole new ball of yarn. Interesting idea. If people willing to state they will complete items for the next release, I can add this to the TODO list, and just remove it once the item is in CVS. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 8.2 features status
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Bruce Momjian) wrote: Joshua D. Drake wrote: For example: Make postmater and postgres options distinct so the postmaster -o option is no longer needed | PeterE | Confirmed for 8.2 | 07/20/06 We could do that, but once an item is done I don't see the point in having the date and person's name. You are right that is clearly a different purpose from the TODO list, and if someone wants to track that, it might help things. The idea of the above is not to track when it is done. THe confirmed is to track that development is taking place and that we have confirmed from the developer that they think it will be done for 8.2. Oh, confirmed confused me. Maybe anticipated or planned for 8.2. It is something that in theory would update throughout the cycle 3 or 4 times. You could even have: Make postmater and postgres options distinct so the postmaster -o option is no longer needed | PeterE | Confirmed for 8.2 | 04/20/06 Make postmater and postgres options distinct so the postmaster -o option is no longer needed | PeterE | Trouble encountered | 06/20/06 Make postmater and postgres options distinct so the postmaster -o option is no longer needed | PeterE | Asks for help | 08/20/06 Make postmater and postgres options distinct so the postmaster -o option is no longer needed | Alvaro | Confirmed | 09/20/06 Notice the sequence of events. I am not saying the specific statuses are the way to go but it would give a simple way to keep tabs on things without having to create a whole new ball of yarn. Interesting idea. If people willing to state they will complete items for the next release, I can add this to the TODO list, and just remove it once the item is in CVS. Is it forcibly necessary to have that commitment in order for this to be of some use? It seems to me that this would be a reasonably useful way of tracking the progress of TODO items irrespective of any particular commitment to completion in sync with a version. -- (reverse (concatenate 'string moc.liamg @ enworbbc)) http://linuxdatabases.info/info/languages.html When aiming for the common denominator, be prepared for the occasional division by zero. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2 features status
Christopher Browne wrote: Make postmater and postgres options distinct so the postmaster -o option is no longer needed | Alvaro | Confirmed | 09/20/06 Notice the sequence of events. I am not saying the specific statuses are the way to go but it would give a simple way to keep tabs on things without having to create a whole new ball of yarn. Interesting idea. If people willing to state they will complete items for the next release, I can add this to the TODO list, and just remove it once the item is in CVS. Is it forcibly necessary to have that commitment in order for this to be of some use? It seems to me that this would be a reasonably useful way of tracking the progress of TODO items irrespective of any particular commitment to completion in sync with a version. The problem comes with someone starting to work on something, then giving up, but if you record it, people think they are still working on it. What happens now is that someone says they want to work on X, and the community tells them that Y might be working on it, and Y gives us a status. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
[EMAIL PROTECTED] (Bruce Momjian) writes: Christopher Browne wrote: Make postmater and postgres options distinct so the postmaster -o option is no longer needed | Alvaro | Confirmed | 09/20/06 Notice the sequence of events. I am not saying the specific statuses are the way to go but it would give a simple way to keep tabs on things without having to create a whole new ball of yarn. Interesting idea. If people willing to state they will complete items for the next release, I can add this to the TODO list, and just remove it once the item is in CVS. Is it forcibly necessary to have that commitment in order for this to be of some use? It seems to me that this would be a reasonably useful way of tracking the progress of TODO items irrespective of any particular commitment to completion in sync with a version. The problem comes with someone starting to work on something, then giving up, but if you record it, people think they are still working on it. If there is some form of last updated on date, that seems to me to be quite sufficient for the purpose. If the person last working on it hasn't reported any new news on the item in some substantial period of time, that's a good implicit indication that something is stalled. What happens now is that someone says they want to work on X, and the community tells them that Y might be working on it, and Y gives us a status. If what we see in the todo is... Implement hierarchical queries using ANSI WITH/recursive query system | Someone | Under way | [some date six months ago] ... then those that are interested in seeing this go in can probably guess that the effort has stalled in that nothing has been worth commenting on in six months. This sort of thing is suggestive of having some sort of systematic way to store structured information. Perhaps one could implement some sort of database for it... :-) -- output = (cbbrowne @ acm.org) http://cbbrowne.com/info/sgml.html Rules of the Evil Overlord #21. I will hire a talented fashion designer to create original uniforms for my Legions of Terror, as opposed to some cheap knock-offs that make them look like Nazi stormtroopers, Roman footsoldiers, or savage Mongol hordes. All were eventually defeated and I want my troops to have a more positive mind-set. http://www.eviloverlord.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.2 features status
If what we see in the todo is... Implement hierarchical queries using ANSI WITH/recursive query system | Someone | Under way | [some date six months ago] ... then those that are interested in seeing this go in can probably guess that the effort has stalled in that nothing has been worth commenting on in six months. This sort of thing is suggestive of having some sort of systematic way to store structured information. Perhaps one could implement some sort of database for it... :-) Mysql should be able to handle something like that nicely. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.2 features status
Bruce, What happens now is that someone says they want to work on X, and the community tells them that Y might be working on it, and Y gives us a status. What happens now is: A starts working on X. 3 months pass B comes to hackers, spends hours reading the archives, doesn't find X (because they know it by a different name), comes to -hackers and asks Is anyone working on X? B waits for 2 weeks without an answer and repeats the question. Hackers E, F and G reply yes, someone is but I don't remember who, search the archives for keyword X B searches again, finds original post. B e-mails A and gets no response. B finally offers to take over X Hackers M, L, and N say sure, but read the archives for spec info B reads more archives for several hours. There's a LOT of unnecessary overhead in that process: having a simple web app that lists who claimed what todo and when, any status updates if they've voluntarily provided them, and links to archive discussions, we could reduce the above to a 3-step process making it vastly easier for new hackers to get started. To be clear: I'm not trying to solve a problem for existing hackers, for whom the existing system works fine. I'm trying to solve a problem for two groups: new hackers, and users who want to check the plans for new features without combing through the archives. I'll also point out that having an annotated TODO with regular updates would lessen the pressure we get from some parties for a roadmap. --Josh ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.2 features status
On Aug 8, 2006, at 17:47 , Josh Berkus wrote: What happens now is: A starts working on X. 3 months pass B comes to hackers, spends hours reading the archives, doesn't find X (because they know it by a different name), comes to -hackers and asks Is anyone working on X? B waits for 2 weeks without an answer and repeats the question. Hackers E, F and G reply yes, someone is but I don't remember who, search the archives for keyword X B searches again, finds original post. B e-mails A and gets no response. B finally offers to take over X Hackers M, L, and N say sure, but read the archives for spec info B reads more archives for several hours. There's a LOT of unnecessary overhead in that process: having a simple web app that lists who claimed what todo and when, any status updates if they've voluntarily provided them, and links to archive discussions, we could reduce the above to a 3-step process making it vastly easier for new hackers to get started. A developers' wiki with links into the list archives would be great. -M ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
Josh Berkus wrote: Bruce, What happens now is that someone says they want to work on X, and the community tells them that Y might be working on it, and Y gives us a status. What happens now is: A starts working on X. 3 months pass B comes to hackers, spends hours reading the archives, doesn't find X (because they know it by a different name), comes to -hackers and asks Is anyone working on X? B waits for 2 weeks without an answer and repeats the question. Hackers E, F and G reply yes, someone is but I don't remember who, search the archives for keyword X I would bet, right about here we loose a whole lot of would be contributors. Just the the questions I had about two todos this year was enough basically give up on doing any work on them. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.2 features status
OK, seems this should be a separate application, not done in the TODO list, and I am not willing to take on that additional workload. --- Josh Berkus wrote: Bruce, What happens now is that someone says they want to work on X, and the community tells them that Y might be working on it, and Y gives us a status. What happens now is: A starts working on X. 3 months pass B comes to hackers, spends hours reading the archives, doesn't find X (because they know it by a different name), comes to -hackers and asks Is anyone working on X? B waits for 2 weeks without an answer and repeats the question. Hackers E, F and G reply yes, someone is but I don't remember who, search the archives for keyword X B searches again, finds original post. B e-mails A and gets no response. B finally offers to take over X Hackers M, L, and N say sure, but read the archives for spec info B reads more archives for several hours. There's a LOT of unnecessary overhead in that process: having a simple web app that lists who claimed what todo and when, any status updates if they've voluntarily provided them, and links to archive discussions, we could reduce the above to a 3-step process making it vastly easier for new hackers to get started. To be clear: I'm not trying to solve a problem for existing hackers, for whom the existing system works fine. I'm trying to solve a problem for two groups: new hackers, and users who want to check the plans for new features without combing through the archives. I'll also point out that having an annotated TODO with regular updates would lessen the pressure we get from some parties for a roadmap. --Josh -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
Bruce, OK, seems this should be a separate application, not done in the TODO list, and I am not willing to take on that additional workload. That's my feeling. But I think that we have enough people who are interested to maintain it. If we don't, there was no point anyway. --Josh ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.2 features status
bruce wrote: OK, seems this should be a separate application, not done in the TODO list, and I am not willing to take on that additional workload. Let me add that anyone who has CVS commit access or wants to submit TODO patches can keep the TODO updated in this way. --- --- Josh Berkus wrote: Bruce, What happens now is that someone says they want to work on X, and the community tells them that Y might be working on it, and Y gives us a status. What happens now is: A starts working on X. 3 months pass B comes to hackers, spends hours reading the archives, doesn't find X (because they know it by a different name), comes to -hackers and asks Is anyone working on X? B waits for 2 weeks without an answer and repeats the question. Hackers E, F and G reply yes, someone is but I don't remember who, search the archives for keyword X B searches again, finds original post. B e-mails A and gets no response. B finally offers to take over X Hackers M, L, and N say sure, but read the archives for spec info B reads more archives for several hours. There's a LOT of unnecessary overhead in that process: having a simple web app that lists who claimed what todo and when, any status updates if they've voluntarily provided them, and links to archive discussions, we could reduce the above to a 3-step process making it vastly easier for new hackers to get started. To be clear: I'm not trying to solve a problem for existing hackers, for whom the existing system works fine. I'm trying to solve a problem for two groups: new hackers, and users who want to check the plans for new features without combing through the archives. I'll also point out that having an annotated TODO with regular updates would lessen the pressure we get from some parties for a roadmap. --Josh -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
Josh Berkus wrote: Bruce, OK, seems this should be a separate application, not done in the TODO list, and I am not willing to take on that additional workload. That's my feeling. But I think that we have enough people who are interested to maintain it. If we don't, there was no point anyway. /me raises his hand .. I already have a wiki I use to help maintain the php.net semi official release todo list: http://oss.backendmedia.com/PHPTODO/ But its running on MySQL .. However since it was easy for me to add a subwiki [1] I just did that and gave the world read/write access. I am sure someone else will soon step up and provide something nicer running on PostgreSQL :) regards, Lukas [1] http://oss.backendmedia.com/PGSQLTODO/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.2 features status
Lukas Smith wrote: Josh Berkus wrote: OK, seems this should be a separate application, not done in the TODO list, and I am not willing to take on that additional workload. That's my feeling. But I think that we have enough people who are interested to maintain it. If we don't, there was no point anyway. /me raises his hand .. I'd vote for a Trac site. I've found it to be a rather useful tool in general, though a bit too simple-minded; integrated Wiki, a simple bugtracker, and roadmap-style reports for people who cares about such stuff. I don't think we'd use the SCM module though. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
I'd vote for a Trac site. I've found it to be a rather useful tool in general, though a bit too simple-minded; integrated Wiki, a simple bugtracker, and roadmap-style reports for people who cares about such stuff. I don't think we'd use the SCM module though. Oddly enough if anything we could use the SCM module for viewing/changest etc... I already have it regenerating itself over at http://projects.commandprompt.com/public/pgsql Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
Can you guys conceive of the thousands of hours of chat you guys are racking upinstead of real hacking because you have an inadequate working structure? This is by far the chattiest and least worthwhile listserv in the bsd world. Bar none. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.7/411 - Release Date: 8/7/2006 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.2 features status
Joshua D. Drake wrote: I don't think we'd use the SCM module though. Oddly enough if anything we could use the SCM module for viewing/changest etc... I already have it regenerating itself over at http://projects.commandprompt.com/public/pgsql I've found that repository view to be broken at certain spots. I'm not sure if the problem is in cvs2svn or Trac itself. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.2 features status
Alvaro Herrera wrote: Joshua D. Drake wrote: I don't think we'd use the SCM module though. Oddly enough if anything we could use the SCM module for viewing/changest etc... I already have it regenerating itself over at http://projects.commandprompt.com/public/pgsql I've found that repository view to be broken at certain spots. I'm not sure if the problem is in cvs2svn or Trac itself. Likely cvs2svn I would guess it is a large repository. I wouldn't expect it to be used instead of CVS but I could see it being useful for reference from a ticket or todo or something. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.2 features status
bruce wrote: bruce wrote: OK, seems this should be a separate application, not done in the TODO list, and I am not willing to take on that additional workload. Let me add that anyone who has CVS commit access or wants to submit TODO patches can keep the TODO updated in this way. I can also give someone ssh access to my server with the ability to modify only the TODO list. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2 features status
I'm constantly amazed at the way people get worked up about X-is-not-there *after* feature freeze. If you wanted it in 8.2, the time to be throwing resources at the problem was six months ago. It's not like Oleg and Teodor haven't let it be known that they could use financing. I would say that Tsearch2 is not a deal breaker. I always express: Yes PostgreSQL has Full Text Indexing, it is just not enabled by default. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
-Original Message- From: Tom Lane [EMAIL PROTECTED] To: Greg Sabino Mullane [EMAIL PROTECTED] Cc: pgsql-hackers@postgresql.org pgsql-hackers@postgresql.org Sent: 07/08/06 04:42 Subject: Re: [HACKERS] 8.2 features status I'm constantly amazed at the way people get worked up about X-is-not-there *after* feature freeze. If you wanted it in 8.2, the time to be throwing resources at the problem was six months ago. It's not like Oleg and Teodor haven't let it be known that they could use financing. The wxWidgets folks have a bounty page where potential sponsors can advertise features they want an how much they'll pay for them. Perhaps we should look at such a page, as well as the reverse where hackers can say I'll do foo, but I need $500 to fund it. Regards, Dave ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.2 features status
On Fri, Aug 04, 2006 at 11:57:03AM -0500, Kenneth Marshall wrote: On Fri, Aug 04, 2006 at 12:40:36PM -0400, Tom Lane wrote: Guillaume Smet [EMAIL PROTECTED] writes: And what about compression of on-disk sorting? That's purely a performance issue, which some people seem to want to define as not a new feature ... which is not *my* view of what's important ... regards, tom lane From my point of view, some of these new performance features are the most important changes in the 8.2 release. We are using other databases currently because of performance problems that are going to be addressed in this release. If we can use PostgreSQL instead, their are new possibilities for reliability and robustness that our current database choice will not allow. The problem with 'performance improvements' from a PR standpoint is that they're not very sexy unless you've got some numbers to go with them. 8.2 has many performance improvements - yawn. On average, users have seen 40% performance improvements in 8.2, and in some cases performance increased over 1000% - wow! Have you by chance done any performance testing with HEAD that can be compared to 8.1? -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.2 features status
On Sat, Aug 05, 2006 at 11:31:24AM -0400, Andrew Dunstan wrote: Bruce Momjian wrote: The fact is, the existing system worked as it should, though it is often invisible. We didn't get all the features we wanted, but that isn't because the system isn't working. Thank you Bruce. That is good to know. Maybe the invisibility has led me astray. I'll shut up now and see if I can actually get Enums and some other good stuff done by this time next year. With any luck I won't be quite as derailed as I was last cycle. Also, I hope it's now clear at least that there are many people who want to see recursive queries. Since some folks are waving the banner of 'open source software' around, why do we have some kind of invisible process for following up on what is and isn't being worked on? In this case, had it been mentioned publicly that recursive queries were getting pushed aside due to perceived lack of user interest, people would have spoken out about it early on enough that it probably could have made it into 8.2. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
On Fri, Aug 04, 2006 at 09:58:08PM -0400, Tom Lane wrote: [EMAIL PROTECTED] writes: Greg, you are on an utterly wrong track here. Try to look about a bit more broadly. FWIW, I tend to agree with Greg. This project has gotten to where it is with a very loose structure, and I think that trying to impose more structure carries a significant risk of breaking the cooperative dynamics that have worked so well for us so far. In short, I'm not sure that we should try to fix something that isn't clearly broken. On the other hand, such an informal system only scales so far. It doesn't seem onerous to me that when someone claims something on the TODO that the TODO reflects that they've claimed it and when. To answer Greg's question about non-commercial projects with a 'formal development process', FreeBSD has someone publish quarterly status reports of where everything's at, and AFAIK there's no commercial sponsorship (except for a few limited cases, like PHK). I don't object to someone informally polling people who have claimed a TODO item and not produced any visible progress for awhile. But I think anything like thou shalt report in once a week will merely drive people away from publicly claiming items, if not drive them away from doing anything at all. We've already got far too much problem with lack of visibility, in the sense that people pop up with patches after not having told anyone they were working on a given problem (much less posted a preliminary design for feedback, as I desperately wish people would do before starting to code anything). We should encourage people to say I'm working on X, and I fear that putting requirements on them as soon as they say that will mostly serve to keep them from saying anything. Perhaps having an easy interface on the TODO would be a way to foster that... an I want to work on this item button that would email whoever claimed an item hints like please come up with a design and discuss it on -hackers before you start coding. And it shouldn't be hard to set that up so that it's not a burden for regular committers (ie: have a list of email addresses not to send those notices out to). BTW, such a system should make it much easier to come up with release notes/major features list for each release. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
On Fri, Aug 04, 2006 at 10:30:26PM -0400, Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: As I was saying on #postgresql, the current system works well for a small group of developers. I don't think there is any arguing that. However, there is a larger group out there, that would likely be willing to contribute but we are a bit of a black box, or perhaps we are too transparent?? I am not sure which. Maybe I'm too much on the inside, but I see the problem the other way 'round: too little visibility of what's being done by people who are not part of the inner circle of developers. It's possible that creating a more formal structure would aid these folk to let the rest of us know what they're doing ... but I think it's at least as likely that a more formal structure would just drive them away. On projects with bug trackers, it's not uncommon to see someone post a patch out-of-the-blue. It's also not uncommon to see folks who help out with trianging bugs and what-not, but don't necessarily do development. This happens because the tools are there to facilitate it. Perhaps more importantly, people now have the expectation that this is how things work, because it's what most OSS projects do. I'm not trying to bring up the bug tracker war, but it's a good example of how we've effectively thrown up barriers to people who want to contribute because of how different all our processes are. I am actually hoping that jabber.postgresql.org would help that in the long run. Now here I think we might be on the same page. If people pop up on IRC or jabber or any other communication method and talk about what they're doing, that fixes the whole problem. I'm for adding anything that provides an opportunity for people to talk to the community --- I'm not for trying to force them to talk to the community, 'cause I don't think that will work very well. Don't put too many eggs in that basket. The problem with jabber and IRC is that once a conversation's over, it's only in the minds of whoever happened to witness it in real-time (sure, people log, but who actually reads IRC logs unless they're looking for something specific). There's a lot of opportunity for *less* communication, because you'll only get info from whoever happens to be watching the channel at that time. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
On Sat, Aug 05, 2006 at 03:55:17PM -0700, Ron Mayer wrote: [EMAIL PROTECTED] wrote: Ron Mayer wrote: We have not had that many cases where lack of communication was a problem. One could say too much communication was the problem this time. I get the impression people implied they'd do something on a TODO and didn't. Arguably the project had been better off if noone had claimed the TODO, so if another company/team/whatever needed the feature badly, they could have worked on it themselves rather than waiting in hope of the feature. This is just perverse. Surely you are not seriously suggesting that we should all develop in secret and then spring miracles fully grown on the community? Of course not. What I'm suggesting is two things. (1) That misleading information is worse than no information; and that speculative information next to TODOs can do as much harm discouraging others as it the good it does for communication. Perhaps a name/assignment/claim on a todo might be nice if someone wanted a private conversation with someone who knows about a feature; but even there wouldn't a public discussion on the lists likely be better? Yes, a name by itself is pretty useless. Having an idea of the status of that TODO item is a completely different story. If one month after claiming an item the status is the old patch I thought would work is junk, this will need to be written from scratch, help wanted! then clearly anyone who's interested in that item and had the ability to help would know that now was the time to step up. Going one step further, if that item was in a system that allowed people to get emails any time status changed then *everyone* who was interested in that feature would immediately know that help was needed. I fail to see how that's a bad thing. (2) That much corporate development on BSD projects is indeed developed in secret. Although may want to be contributed later either because the company no longer decides it's a trade-secret or gets tired of maintaining their own fork. Sure, such patches might need even more discussion and revision than if they were designed with core - but I think it's a reality that such work exists. I think this goes way beyond patches... there's got to be dozens of home-grown scripts to handle PITR (for one example). Granted, most of those will be rather specific to an individual environment, but if people would at least share them then someone setting up PITR for the first time wouldn't have to start from scratch. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.2 features status
Jim C. Nasby wrote: Going one step further, if that item was in a system that allowed people to get emails any time status changed then *everyone* who was interested in that feature would immediately know that help was needed. I fail to see how that's a bad thing. Or maybe even more importantly if the status did not change. regards, Lukas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2 features status
Bruce, The fact is, the existing system worked as it should, though it is often invisible. We didn't get all the features we wanted, but that isn't because the system isn't working. But it's exactly the invisibility of the process which people are complaining about. If the postgresql novice, it's darned near impossible to figure our who is working on feature X and what it's status or specification is. Your TODO just doesn't reflect current enough information. We've had this dicussion, or one similar to it, each release for the past 3 releases. Obviously other people feel that there's an issue, even if *you* don't. Also, the current nature of the system has a bus-factor of 1; that is, if you get hit by a bus NOBODY else has the information you have in your head (I seem to recall you harassing Marc about similar single-point-of-failure issues). We need a Bruce brain-dump to the web, even if someone else has to do the typing. --Josh ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
Josh Berkus wrote: Bruce, The fact is, the existing system worked as it should, though it is often invisible. We didn't get all the features we wanted, but that isn't because the system isn't working. But it's exactly the invisibility of the process which people are complaining about. If the postgresql novice, it's darned near impossible to figure our who is working on feature X and what it's status or specification is. Your TODO just doesn't reflect current enough information. Right. I think we want people to announce to the lists before they start on a patch. Often we can give advice and if someone else is working on it, they can mention that. I don't think our TODO list will ever allow people to start working effectively without asking the community. We've had this discussion, or one similar to it, each release for the past 3 releases. Obviously other people feel that there's an issue, even if *you* don't. OK, they are free to use other methods. I am not stopping them. The TODO list marks items as done, but doesn't really track who is working on what. Also, the current nature of the system has a bus-factor of 1; that is, if you get hit by a bus NOBODY else has the information you have in your head (I seem to recall you harassing Marc about similar single-point-of-failure issues). We need a Bruce brain-dump to the web, even if someone else has to do the typing. I know about the same as the community members who pay attention to postings. What I do is to act on that information by contacting developers and asking them to complete their work for feature freeze. Many of my conversations are not appropriate for the public, which is why it is done privately. In fact, the feedback I have gotten from some community members that have heard a little of the discussions I have had with developers is that I am too forceful. I know that doesn't match my often non-critical or even lax handling of things, but I take my community responsibility seriously, and if someone has stated they are working on an item, I expect them to take that pledge seriously as well. As far as people always asking for better tracking, they used to always ask for a roadmap, and when we stated we couldn't because we have no control over developers, they pointed to Mozilla, which had a roadmap at the time (but we know what happened to them.) In the case of recursive queries, I did more than might have even been polite to try to get the developer to complete it. I don't see how changing our system is going to improve it. If you want to change the system, find a system that would have actually done better than what we have in place. Or try a new system, and I will keep doing what I do, and we can see which system works best. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
Joshua D. Drake wrote: The fact is, the existing system worked as it should, though it is often invisible. We didn't get all the features we wanted, but that isn't because the system isn't working. Well that kind of comes back to my point of better communication. Perhaps a lot of this discussion could have been avoided if the TODO had been more... proactive? For example: Make postmater and postgres options distinct so the postmaster -o option is no longer needed | PeterE | Confirmed for 8.2 | 07/20/06 We could do that, but once an item is done I don't see the point in having the date and person's name. You are right that is clearly a different purpose from the TODO list, and if someone wants to track that, it might help things. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2 features status
On Sat, 5 Aug 2006, Peter Eisentraut wrote: Joshua D. Drake wrote: Frankly, I don't care if we ever get a bug tracker or use trac. However a more formalized communication process is sorely needed IMHO. There's also supposed to be a wiki set up. Working on that, hope to have it up Sunday ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2 features status
On Fri, Aug 04, 2006 at 12:40:36PM -0400, Tom Lane wrote: Guillaume Smet [EMAIL PROTECTED] writes: And what about compression of on-disk sorting? That's purely a performance issue, which some people seem to want to define as not a new feature ... which is not *my* view of what's important ... regards, tom lane From my point of view, some of these new performance features are the most important changes in the 8.2 release. We are using other databases currently because of performance problems that are going to be addressed in this release. If we can use PostgreSQL instead, their are new possibilities for reliability and robustness that our current database choice will not allow. Ken ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
# kleptog@svana.org / 2006-08-05 15:49:33 +0200: On Fri, Aug 04, 2006 at 06:25:35PM -0700, Joshua D. Drake wrote: I have heard you make this argument before, and it is just is not true. Even Debian is moving toward a more formal structure as has FreeBSD. You seem stuck in this world where everything is still 1994 and all FOSS software is developed in academia. Debian moving towards a more formal structure? What I seeing is that they're trying to get away from the having one person responsible for things to working in groups. What it amounts to is simplifying the rules to doing someone elses work. People who don't like it leave and you hope you're left with a more efficient group. The links you provide are mostly about handling releases. To be honest, I think PostgreSQL's release handling is fine. But none of those projects tackles the issue of making sure certain things get done. If someone didn't do the work for getting GCC 4.1 working for Debian, then no matter how much of a release goal it was, it wouldn't happen... Actually, the FreeBSD team does gather status reports from people working on major tasks. Max Laier bugs current@ and hackers@ every two months, [1] then publishes whatever came in. [2,3] They used to ask for emails IIRC, now I see there's a report submission form on the web. [4] [1] http://marc.theaimsgroup.com/?l=freebsd-currentm=115126459006810 [2] http://marc.theaimsgroup.com/?l=freebsd-currentm=115265674914807 [3] http://www.freebsd.org/news/status/ [4] http://www.freebsd.org/cgi/monthly.cgi -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
On Aug 5, 2006, at 10:48 PM, Christopher Browne wrote: Quoth [EMAIL PROTECTED] (David Fetter): On Fri, Aug 04, 2006 at 02:37:56PM -0700, Neil Conway wrote: On Fri, 2006-08-04 at 12:40 -0700, David Fetter wrote: While I am not going to reopen the can of worms labeled 'bug tracker', I think it would be good to have a little more formality as far as claiming items goes. What say? I think this is a good plan for adding additional process overhead, and getting essentially nothing of value in return. I'm not convinced there's a problem in need of solving here... Perhaps you'd like to explain how big a burden on the developer it is to send an once a week, that being what I'm proposing here. As far as the problem in need of solving, it's what Andrew Dunstan referred to as splendid isolation, which is another way of saying, letting the thing you've taken on gather dust while people think you're working on it. It seems to me once a week is a bit too often to demand, particularly when trying to herd cats. A burden of once a month may seem more reasonable. One of the problems is that CVS branching is rather painful and some contributors can't commit. If there were some place where one could maintain a publicly-visible development branch just for feature X, that would make the work open source and trackable instead of open-source-once-I'm-done. -M ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ AgentM [EMAIL PROTECTED] ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My impression from this post http://archives.postgresql.org/pgsql-hackers/2006-07/msg00556.php was that moving it into core should be doable for 8.3. I hope I didn't misunderstand. As I've stated before, it sure would be nice if there was any possible way this could be done for 8.2. This would be a *huge* feature for 8.2 to have, and it frankly needs all the big-item-yet-easy-to-grasp features it can get. Is there any way this could be done if we threw money and/or people at the problem? I'm sure we could come up with both if the end goal was having built-in text searching for the next release. - -- Greg Sabino Mullane [EMAIL PROTECTED] [EMAIL PROTECTED] End Point Corporation PGP Key: 0x14964AC8 200608062228 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iD8DBQFE1qjEvJuQZxSWSsgRApwuAJ9Dva+SNpnWi5a1C/xGDLeP0ZyI4QCeL5NW KSq5zQoVpD7U7oP2JdYgxu0= =bDQg -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.2 features status
Greg, As I've stated before, it sure would be nice if there was any possible way this could be done for 8.2. This would be a *huge* feature for 8.2 to have, and it frankly needs all the big-item-yet-easy-to-grasp features it can get. Is there any way this could be done if we threw money and/or people at the problem? I'm sure we could come up with both if the end goal was having built-in text searching for the next release. Maybe you've said this before, but why is the current regexp support not good enough? What kind of response time, etc, do you need? - Luke ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.2 features status
Greg Sabino Mullane wrote: My impression from this post http://archives.postgresql.org/pgsql-hackers/2006-07/msg00556.php was that moving it into core should be doable for 8.3. I hope I didn't misunderstand. As I've stated before, it sure would be nice if there was any possible way this could be done for 8.2. This would be a *huge* feature for 8.2 to have, and it frankly needs all the big-item-yet-easy-to-grasp features it can get. Is there any way this could be done if we threw money and/or people at the problem? I'm sure we could come up with both if the end goal was having built-in text searching for the next release. I suspect the train is too far out of the station. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 8.2 features status
Greg Sabino Mullane [EMAIL PROTECTED] writes: Is there any way this could be done if we threw money and/or people at the problem? No. I'm constantly amazed at the way people get worked up about X-is-not-there *after* feature freeze. If you wanted it in 8.2, the time to be throwing resources at the problem was six months ago. It's not like Oleg and Teodor haven't let it be known that they could use financing. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2 features status
If people are going to start listing features they want here's some things I think would be nice. I have no idea though if they would be useful to anyone else: 1) hierarchical / recursive queries. I realize it's just been discussed at length but since there was some question as to whether or not there's demand for it so I am just weighing in that I think there is. I have to deal with hierarchy tables all the time and I simply have several standard methods of dealing with them depending on the data set / format. But they all suck. I've just gotten use to using the workarounds since there is nothing else. If you are not hearing the screams it's just because I think it's just become a fact of life for most people (unless you're using oracle) that you've just got to work around it. And everyone already has some code to do this and they've already done it everywhere it needs to be done. And as long as you're a little bit clever you can always work around it without taking a big performance hit. But it would sure be nice to have next time I have to deal with a tree table. 2) PITR on a per database basis. I think this would be nice but I'm guessing that the work involved is big and that few people really care or need it, so it will probably never happen. 3) A further refinement of PITR where some sort of deamon ships small log segments as they are created so that the hot standby doesn't have to be updated in 16MB increments or have to wait for some timeout to occur. It could always be up to the minute data. 4) All the Greenplum Bizgress MPP goodness. In reality (and I don't know if bizgress mpp can actually do this) I'd like to have a cluster of cheap boxes. I'd like to install postgres on all of them and configure them in such a way that it automatically partitions and mirrors each table so that each piece of data is always on two boxes and large tables and indexes get divided up intelligently. Sort of like a raid10 on the database level. This way any one box could die and I would be fine. Enormous queries could be handled efficiently and I could scale up by just dropping in new hardware. Maybe greeenplum has done this. Maybe we will get their changes soon enough, maybe not. Maybe this sort of functionality will never happen. My guess is that all the little bit's a pieces of this will trickle in over the next several years and this sort of setup will be slowly converged on over time as lot's of little things come together. Table spaces and constraint exclusion come to mind here as things that could eventually evolve to contribute to a larger solution. 5) Somehow make it so I NEVER HAVE TO THINK ABOUT OR DEAL WITH VACUUM AGAIN. Once I get everything set up right everything works great but I'm sure if there's one thing I think everyone would love it would be getting postgres to the point where you don't even need to ship vacuumdb because there's no way the user could outsmart postgres's attempts to do garbage collection on it's own. 6) genuine updatable views. such that you just add an updatable keyword when you create the view and it's automagically updatable. I'm guessing that we'll get something like that, but its real magic will be throwing an error to tell you when you try to make a view updatable and it can't figure out how to make the rules properly. 7) allow some way to extract the data files from a single database and insert them into another database cluster. In many cases it would be a lot faster to copy the datafiles across the network than it is to dump, copy dump file, reload. 8) some sort of standard hooks to be used for replication. I guess when the replication people all get their heads together and tell the core developers what they all need something like this could evolve. Like I said, postgres more than satisfies my needs. I am especially happy when you factor in the cost of the software (free), and the quality of the community support (excellent). And you can definitely say that the missing list is shrinking. But I think of it like this. There are tiers of database functionality that different people need: A) Correct me if I'm wrong but as great as postgres is there are still people out there that MUST HAVE Oracle or DB2 to get done what they need to get done. They just do things that the others can't. They may be expensive. They may suck to use and administer but the simple fact is that they have features that people need that are not offered in less expensive databases. B) Very, very powerful databases but lack the biggest, most complicated enterprise features. C) Light weight db for taking care of the basic need to store data and query it with sql. (some would call these toy databases) D) databases which are experimental, unreliable or have other limits that make them not practical compared with the other options I
Re: [HACKERS] 8.2 features status
Joshua D. Drake wrote: Frankly, I don't care if we ever get a bug tracker or use trac. However a more formalized communication process is sorely needed IMHO. There's also supposed to be a wiki set up. There, people can try to make up tracking lists, project management, task lists, release goals or whatever on their own. If patterns emerge, we can formalize them, but I feel this would be a good way to try things out. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
[EMAIL PROTECTED] writes: I don't object to someone informally polling people who have claimed a TODO item and not produced any visible progress for awhile. But I think anything like thou shalt report in once a week will merely drive people away from publicly claiming items, if not drive them away from doing anything at all. The former is much more what I had in mind than the latter. Let's do that. Like I said, no objection here. But who exactly is we --- ie, who's going to do the legwork? We surely don't want multiple people pestering the same developer ... Perl has its pumpking ... maybe we need a designated holder of the trunk. I see that as a Core function. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.2 features status
On Sat, Aug 05, 2006 at 12:19:54AM -0400, Matthew T. O'Connor wrote: Robert Treat wrote: So, the things I hear most non-postgresql people complain about wrt postgresql are: no full text indexing built in FTI is a biggie in my mind. I know it ain't happening for 8.2, but is the general plan to integrate TSearch2 directly into the backend? When the Tsearch developers say so I think. This will be the first major release with GIN which will form the basis of future releases of tsearch. IIRC they have a whole list of features they still want to add before it gets included... Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] 8.2 features status
Tom Lane wrote: But a quick troll through the CVS logs shows ... multi-row VALUES, not only for INSERT but everywhere SELECT is allowed ... multi-argument aggregates, including SQL2003-standard statistical aggregates ... standard_conforming_strings can be turned on (HUGE deal for some people) ... support SQL-compliant row comparisons; they can be indexscan quals ISTM this could be spun as a standards-focused release as well (at least partial implementations of a number of optional(?) SQL2003 features). ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
On Fri, Aug 04, 2006 at 06:25:35PM -0700, Joshua D. Drake wrote: I have heard you make this argument before, and it is just is not true. Even Debian is moving toward a more formal structure as has FreeBSD. You seem stuck in this world where everything is still 1994 and all FOSS software is developed in academia. Debian moving towards a more formal structure? What I seeing is that they're trying to get away from the having one person responsible for things to working in groups. What it amounts to is simplifying the rules to doing someone elses work. People who don't like it leave and you hope you're left with a more efficient group. The links you provide are mostly about handling releases. To be honest, I think PostgreSQL's release handling is fine. But none of those projects tackles the issue of making sure certain things get done. If someone didn't do the work for getting GCC 4.1 working for Debian, then no matter how much of a release goal it was, it wouldn't happen... That means you let people know if you are not going to finish something, if you need help, if you can't help, or if you are going to bail on a project. You should also do so with (hopefully) the ability for someone to pick up where you left off. That I can agree with, but I don't think you can force it. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] 8.2 features status
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: I don't object to someone informally polling people who have claimed a TODO item and not produced any visible progress for awhile. But I think anything like thou shalt report in once a week will merely drive people away from publicly claiming items, if not drive them away from doing anything at all. The former is much more what I had in mind than the latter. Let's do that. Like I said, no objection here. But who exactly is we --- ie, who's going to do the legwork? We surely don't want multiple people pestering the same developer ... Perl has its pumpking ... maybe we need a designated holder of the trunk. I see that as a Core function. I can assure you that individual developers were contacted about completing their items for 8.2, to the extent that some developers got upset at me because of my insistence. If they were hired by PostgreSQL companies and I had a relationship with their manager, their managers were informed as well. Jonah, who said the community wasn't clear it wanted his items completed, was part of that group. I see no need to mention the other people I contacted. Many of them completed their items, and Jonah finished some of his items. The fact is, the existing system worked as it should, though it is often invisible. We didn't get all the features we wanted, but that isn't because the system isn't working. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 8.2 features status
There's also supposed to be a wiki set up. There, people can try to make up tracking lists, project management, task lists, release goals or whatever on their own. If patterns emerge, we can formalize them, but I feel this would be a good way to try things out. Well I will re-extend my offer to put up a trac site for everyone which does contain a wiki. However, last time I offered I believe Marc was actually going to do it. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.2 features status
Bruce Momjian wrote: I can assure you that individual developers were contacted about completing their items for 8.2, to the extent that some developers got upset at me because of my insistence. If they were hired by PostgreSQL companies and I had a relationship with their manager, their managers were informed as well. Jonah, who said the community wasn't clear it wanted his items completed, was part of that group. I see no need to mention the other people I contacted. Many of them completed their items, and Jonah finished some of his items. The fact is, the existing system worked as it should, though it is often invisible. We didn't get all the features we wanted, but that isn't because the system isn't working. Thank you Bruce. That is good to know. Maybe the invisibility has led me astray. I'll shut up now and see if I can actually get Enums and some other good stuff done by this time next year. With any luck I won't be quite as derailed as I was last cycle. Also, I hope it's now clear at least that there are many people who want to see recursive queries. cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
The fact is, the existing system worked as it should, though it is often invisible. We didn't get all the features we wanted, but that isn't because the system isn't working. Well that kind of comes back to my point of better communication. Perhaps a lot of this discussion could have been avoided if the TODO had been more... proactive? For example: Make postmater and postgres options distinct so the postmaster -o option is no longer needed | PeterE | Confirmed for 8.2 | 07/20/06 I *think* it was peter that did that one, but you see my point. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
Martijn van Oosterhout kleptog@svana.org writes: On Sat, Aug 05, 2006 at 12:19:54AM -0400, Matthew T. O'Connor wrote: FTI is a biggie in my mind. I know it ain't happening for 8.2, but is the general plan to integrate TSearch2 directly into the backend? When the Tsearch developers say so I think. Yeah, that's my take too. Oleg and Teodor obviously feel it's not done yet, and ISTM leaving it in contrib gives them more flexibility in a couple of ways: * they can make user-visible API changes without people getting as upset as if they were changing core features; * because it is a removable contrib module, they can (and do) offer back-ports of newer versions to existing PG release branches. I think some descendant of tsearch2 will eventually be in core, but we'll wait till we're pretty certain it's feature-stable. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
Tom Lane wrote: I tend to agree --- I don't see much value in trying to institute a formalized process. One more problem with the formalized process of claiming features in advance may stop what I suspect is a significant source of contributions -- people who add features/patches for internal work in their company and only after the fact find that they are something they'd contribute back. The small contribution I made (to help admins know when FSM settings were too low by monitoring log files instead of manual checks[1]) was done because we wanted it internally. Only after it proved useful to us, it was mentioned to the lists. Thanks in part to the BSD nature of postgresql, I suspect there are many internal-and-not-yet-released useful patches lurking around in industry. If I'm right, I'd wonder what the advocacy guys could do to get corporations to volunteer to contribute changes back that they've found useful internally. We have not had that many cases where lack of communication was a problem. One could say too much communication was the problem this time. I get the impression people implied they'd do something on a TODO and didn't. Arguably the project had been better off if noone had claimed the TODO, so if another company/team/whatever needed the feature badly, they could have worked on it themselves rather than waiting in hope of the feature. Of course they could have done this anyway - but if they see it on an implied roadmap document for the next release they're more likely to wait. Ron [1] http://archives.postgresql.org/pgsql-patches/2005-02/msg00171.php ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2 features status
Ron Mayer wrote: We have not had that many cases where lack of communication was a problem. One could say too much communication was the problem this time. I get the impression people implied they'd do something on a TODO and didn't. Arguably the project had been better off if noone had claimed the TODO, so if another company/team/whatever needed the feature badly, they could have worked on it themselves rather than waiting in hope of the feature. Of course they could have done this anyway - but if they see it on an implied roadmap document for the next release they're more likely to wait. This is just perverse. Surely you are not seriously suggesting that we should all develop in secret and then spring miracles fully grown on the community? We have bumped patches before because they have done things without discussing them, and were found not to be accepatble. The more complex features get, the more communication is needed. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.2 features status
[EMAIL PROTECTED] wrote: Ron Mayer wrote: We have not had that many cases where lack of communication was a problem. One could say too much communication was the problem this time. I get the impression people implied they'd do something on a TODO and didn't. Arguably the project had been better off if noone had claimed the TODO, so if another company/team/whatever needed the feature badly, they could have worked on it themselves rather than waiting in hope of the feature. This is just perverse. Surely you are not seriously suggesting that we should all develop in secret and then spring miracles fully grown on the community? Of course not. What I'm suggesting is two things. (1) That misleading information is worse than no information; and that speculative information next to TODOs can do as much harm discouraging others as it the good it does for communication. Perhaps a name/assignment/claim on a todo might be nice if someone wanted a private conversation with someone who knows about a feature; but even there wouldn't a public discussion on the lists likely be better? (2) That much corporate development on BSD projects is indeed developed in secret. Although may want to be contributed later either because the company no longer decides it's a trade-secret or gets tired of maintaining their own fork. Sure, such patches might need even more discussion and revision than if they were designed with core - but I think it's a reality that such work exists. We have bumped patches before because they have done things without discussing them, and were found not to be accepatble. The more complex features get, the more communication is needed. Agreed, of course. This makes me think that ongoing discussion on hackers patches is the only way to judge progress on a todo; and anything like assigned names estimated dates releases are less likely to be meaningful than what one could infer from discussions on the lists. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
Tom Lane wrote: Martijn van Oosterhout kleptog@svana.org writes: On Sat, Aug 05, 2006 at 12:19:54AM -0400, Matthew T. O'Connor wrote: FTI is a biggie in my mind. I know it ain't happening for 8.2, but is the general plan to integrate TSearch2 directly into the backend? When the Tsearch developers say so I think. Yeah, that's my take too. Oleg and Teodor obviously feel it's not done yet, and ISTM leaving it in contrib gives them more flexibility in a couple of ways: * they can make user-visible API changes without people getting as upset as if they were changing core features; * because it is a removable contrib module, they can (and do) offer back-ports of newer versions to existing PG release branches. I think some descendant of tsearch2 will eventually be in core, but we'll wait till we're pretty certain it's feature-stable. My impression from this post http://archives.postgresql.org/pgsql-hackers/2006-07/msg00556.php was that moving it into core should be doable for 8.3. I hope I didn't misunderstand. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 8.2 features status
In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Jim C. Nasby) transmitted: What say? It's a shame to have a person burn cycles on this, but anything would be an improvement over what we've got now. Anything includes some options that would probably *not* be improvements. I'm not sure that pestering everyone once a week would be a particularly good move. That's too likely to get silly unrealistic estimates as to how much is done. (Entirely typical in run-by-the-calendar projects project managed by Big Five consulting firms...) On the flip side, I don't think it is unreasonable to expect to hear *something* once a month or every two months on ToDo items that have been assigned. With the proviso that if no news is heard in several months, that surely suggests that the item isn't progressing, and might deserve others' attention... -- let name=cbbrowne and tld=acm.org in String.concat @ [name;tld];; http://linuxdatabases.info/info/linuxdistributions.html Rules of the Evil Overlord #79. If my doomsday device happens to come with a reverse switch, as soon as it has been employed it will be melteddown and made into limited-edition commemorative coins. http://www.eviloverlord.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.2 features status
Quoth [EMAIL PROTECTED] (David Fetter): On Fri, Aug 04, 2006 at 02:37:56PM -0700, Neil Conway wrote: On Fri, 2006-08-04 at 12:40 -0700, David Fetter wrote: While I am not going to reopen the can of worms labeled 'bug tracker', I think it would be good to have a little more formality as far as claiming items goes. What say? I think this is a good plan for adding additional process overhead, and getting essentially nothing of value in return. I'm not convinced there's a problem in need of solving here... Perhaps you'd like to explain how big a burden on the developer it is to send an once a week, that being what I'm proposing here. As far as the problem in need of solving, it's what Andrew Dunstan referred to as splendid isolation, which is another way of saying, letting the thing you've taken on gather dust while people think you're working on it. It seems to me once a week is a bit too often to demand, particularly when trying to herd cats. A burden of once a month may seem more reasonable. -- let name=cbbrowne and tld=gmail.com in name ^ @ ^ tld;; http://linuxdatabases.info/info/nonrdbms.html If you pick up a starving dog and make him prosperous, he will not bite you; that is the principal difference between a dog and a man. -- Mark Twain ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.2 features status
+1 UPDATE/DELETE for CE are a big deal - I really wish we had INSERT too, then we'd be able to claim complete support for partitioning, but this is a big deal improvement. - Luke On 8/3/06 9:30 PM, Gavin Sherry [EMAIL PROTECTED] wrote: A lot of the things on Tom's list are new bits of functionality to things added around 8.0 and 8.1 (major enhancements to the usability of constraint exclusion, for example). ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
On Fri, Aug 04, 2006 at 12:37:10AM -0400, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: To me new things are like PITR, Win32, savepoints, two-phase commit, partitioned tables, tablespaces. These are from 8.0 and 8.1. What is there in 8.2 like that? [ shrug... ] Five out of your six items have no basis in the SQL spec. So it's not clear to me what your definition of major feature is, unless maybe it's anything except what we did for 8.2. Can you enumerate ten things you would consider comparable to the above features that aren't done yet? First, I'd like to say people are doing a fantastic job here. Kudos! One huge thing missing from the done list is that crucial bit of infrastructure and process that has shortened feedback loops--hence the beta period--by weeks if not months: the build farm. It's now smoothly integrated into the development process, and as a consequence, we can realistically have a release each year. :) As far as big missing features go, here's a short list: * Splitting queries among CPUs--possibly even among machines--for OLAP loads * In-place upgrades (pg_upgrade) * Several varieties of replication, which I believe we as a project will eventually endorse and ship * CALL * WITH RECURSIVE * MERGE * Windowing functions * On-the-fly in-line calls out to PL/your_choice without needing to issue DDL * Wild-eyed feral bits of the SQL standard like SQL/MED and SQL/XML But all that leaves out the oldest, most honored Postgres tradition: Breaking New Ground. We're definitely not done yet. :) Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 8.2 features status
Ühel kenal päeval, R, 2006-08-04 kell 00:46, kirjutas Bruce Momjian: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: To me new things are like PITR, Win32, savepoints, two-phase commit, partitioned tables, tablespaces. These are from 8.0 and 8.1. What is there in 8.2 like that? [ shrug... ] Five out of your six items have no basis in the SQL spec. So it's not clear to me what your definition of major feature is, unless maybe it's anything except what we did for 8.2. Can you enumerate ten things you would consider comparable to the above features that aren't done yet? No, I cannot. I do think our missing list is shrinking. My point is that you really couldn't easily work around the 8.0/8.1 items I listed if they were missing, while the 8.2 items could be more easily worked-around. The workaround for missing concurrent vacuum was to design your databases so the your small and large OLTP tables are on different servers or that you keep a replica and vacuum your large tables there and then switch over to it. It is debatable if that qualifies as more easily worked-around The workaround for pl/python not allowing returning records and sets was to write an actual pl/python function to generate the data and to store it in global ditionary GD, a set of pl/python data retrieval functions for each postgresql data type used and a wrapper function in pl/pgsql to call the real function and then return the the data records using the data retrieval functions. May be simple, but a real PITA to do for more than one function. I guess some other new features that were missing before were as easy to work around :) Again, nothing wrong with that. Sure. Actually I think that people were able to work around missing features in 8.0/8.1 as well. The proof being, that people *did* actually use postgresql before 8.x , some even on win32 ;) -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.2 features status
David, On 8/3/06 11:02 PM, David Fetter [EMAIL PROTECTED] wrote: * Splitting queries among CPUs--possibly even among machines--for OLAP loads * In-place upgrades (pg_upgrade) * Several varieties of replication, which I believe we as a project will eventually endorse and ship * CALL * WITH RECURSIVE * MERGE * Windowing functions * On-the-fly in-line calls out to PL/your_choice without needing to issue DDL My ordering of this list in terms of priority is: 1) Windowing functions 2) MERGE 3) Index only access (new) 4) In-place upgrades We already have splitting queries among CPUs and machines. - Luke ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.2 features status
All, grin Aren't I, the marketing geek, supposed to be the one whining about this? Seriously, PostgreSQL has the fastest release cycle of any RDBMS project in the world. The request I'm hearing from large production users is to release *less* often. So I don't find it a problem that this release has less checklist features than the last two did, and I don't think anyone else will. If all the pending features die then I might find it a stretch to write the press release, but otherwise, no problem. And since when were we a marketing-driven project anyway? * In-place upgrades (pg_upgrade) BTW, I may get Sun to contribute an engineer for this; will get you posted. Oh, and if it makes it, Tzadhi's FULL DISJUNCTIONS patch is newsworthy. -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2 features status
David Fetter skrev: As far as big missing features go, here's a short list: * Windowing functions If we are to wish for things the window functions and a proper collation/locale support is what I miss the most. /Dennis ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.2 features status
On Fri, Aug 04, 2006 at 08:27:02AM +0200, Dennis Bjorklund wrote: If we are to wish for things the window functions and a proper collation/locale support is what I miss the most. Agreed. The complaints about collation/locale support have been continuous over the years, and it really is quite irritating in certain situations. I got the COLLATE support as far as grammer and executor support but got stuck on the planning and optimiser. Maybe one day I'll get the time to really finish it off properly... (if anyone else wants to have a shot, go for it). One downside of a fast release cycle: fast tree drift :) But I guess you can't really complain about that. Oh yeah, user-defined typmod would be cool. There's some movement on that though. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] 8.2 features status
Bruce Momjian wrote: Right, hence usability, not new enterprise features. I'm not too happy about the label usability. Ok, maybe postgres gets usable finally by supporting features that MySQL had for a long time a MySql guy would say. Regards, Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2 features status
On 04/08/06, Andreas Pflug [EMAIL PROTECTED] wrote: Bruce Momjian wrote: Right, hence usability, not new enterprise features. I'm not too happy about the label usability. Ok, maybe postgres gets usable finally by supporting features that MySQL had for a long time a MySql guy would say. I have the same feeling about the term usability. It could be interpreted like : PostgreSQL was not usable until now. Best wishes, Adrian Maier ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2 features status
On 8/4/06, Luke Lonergan [EMAIL PROTECTED] wrote: My ordering of this list in terms of priority is: 1) Windowing functions 2) MERGE 3) Index only access (new) 4) In-place upgrades And what about compression of on-disk sorting? There has been a long thread about this idea. Is there any news about this feature? IIRC Jim Nasby and Martijn were working on testing that and on validating it was interesting for most of the cases. -- Guillaume ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
Tom Lane wrote: Not that there's anything wrong with a performance-oriented release ... but if you think that 8.2 is short on features, you'd better get ready to be disappointed by every future release. It's a pity that some expectations have been raised about features that we haven't seen patches for, e.g. MERGE and/or some form of UPSERT, and recursive queries. I am not pointing fingers, but I do think we need some way in which the community can ensure that certain goals are met, or at least try to help if things fall in a ditch, rather than just relying on hackers scratching whatever itch they happen to get in splendid isolation and then trying to merge the results. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
