Re: [HACKERS] Mid cycle release?
On Thu, 2006-09-14 at 14:16 -0400, Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: Point I want to make is - all those are cool features(and might be critical for some) but I don't think they warrant a dramatic change in the release cycle policy ... Any release is going to have some things that are compelling and some that aren't, for any particular person ... it's just that those things vary depending on who you are ... I was heard to gripe not long ago that feature freeze during August was bad timing. It would be interesting to try to do it during the spring instead, just to see if people have more free time then. So for me, +1 for a shorter-than-a-year cycle this time, independently of what features make it or don't. July 1 or Aug 1 as the *real* date has always been a problem for me. My kids will be on vacation from school at that time for a few years yet. I'd vote for a date in mid-May, when nobody is on holiday and lots of people are available for 6-8 weeks after Feature Freeze. Specific suggestion: 2nd Monday in May, which falls 14 May in 2007. 8.1 was a short release. If we make 8.3 a short release also, we may as well say the release cycle is 18 months not 12. Seems like we spend a lot of time releasing if we do it that way. :-( If 8.3 is a short release, I would hope that it happens as a permanent move to the new time-of-year, so we can get back to 12 month release cycles (which I like). I'd like to get some clarity on those dates as soon as possible, if they are significantly earlier than May. EDB is planning some major work, so need to see whether those projects are 8.3 or 8.4 timescale. Whatever the date, I'd like to suggest we have 2 sync points a year, not one. Sync point meaning where we clear the patch queue and consolidate, but don't go through the whole release process. That way we won't get this stupidly busy period where Bruce and Tom go into overdrive while everyone else waits before they begin next developments. Checkpoints are a performance issue, as we know. Right now, you can only start big projects once each year and whichever way you cut it, 8.4 is a long way off yet. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Mid cycle release?
Simon Riggs wrote: I'd like to get some clarity on those dates as soon as possible, if they are significantly earlier than May. EDB is planning some major work, so need to see whether those projects are 8.3 or 8.4 timescale. Whatever the date, I'd like to suggest we have 2 sync points a year, not one. Sync point meaning where we clear the patch queue and consolidate, but don't go through the whole release process. That way we won't get this stupidly busy period where Bruce and Tom go into overdrive while everyone else waits before they begin next developments. Checkpoints are a performance issue, as we know. Right now, you can only start big projects once each year and whichever way you cut it, 8.4 is a long way off yet. My guess is that 8.3 will be about at long as 8.2 unless a huge number of must-have features appear early in 8.3, and we will not know that for months. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Mid cycle release?
On Sep 16, 2006, at 9:31 PM, Tom Lane wrote: Jim C. Nasby [EMAIL PROTECTED] writes: Then we should change autovacuum so that it stays out of the way when tables are being vacuumed frequently enough via an external means. What makes you think it doesn't do that already? Of course, it has its own ideas about what frequently enough is, but it won't re-vacuum a table that's been vacuumed within that interval. Oh, I'd forgotten that autovac looked at manual vacuums too. While I personally don't really want autovac on in my development environment, I find it hard to deny the argument that it ought to be on by default. If you know enough to set up a cron job to do your own vacuuming schedule, you *certainly* know enough to turn off autovac if you don't want it, or better dial it down to the point where it's just an emergency backstop for your cron job. If you don't know enough to turn off autovac, then you need it on. And while we're certainly not MS Access, it's worthwhile to make things easy for newbies when it doesn't get in the way of the pros. It's certainly not hard to disable autovac, and anyone who's actually tuning an install is going to be tweaking stuff in postgresql.conf anyway... -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Mid cycle release?
Joshua D. Drake wrote: O.k. that was negative, sorry. Frankly I think that turning autovacuum on by default pretty much equates to, I am lazy, and I don't want to actually evaluate my needs. Lets just go with MS Access Please ignore my negativity today. I apologize. I do not want autovacuum turned on by default but it isn't that big of a deal. Dammit, I was halfway through a brilliant rebuttal! I'm going to post it anyway, since I think it's important to discuss the issues if we're going to make the right call. Your repented negativity is noted, though. :) I can definitely see where you're coming from, it's a sort of tough-love scenario. There are legitimate counter arguments, though. The most obvious is that anyone who *does* evaluate their needs properly shouldn't have too much trouble turning it off, whereas there are lots of small database users out there who find having to set up a vacuum cron a pain. Example: I'm in the process of setting up a typo blog, using postgresql of course, but the database setup was secondary to the main thing that I was doing, and I'd completely forgotten about setting up a cron. Now I'm unlikely to produce blog posts at a rate that will cause the database to grow out of the minuscule range, but it should still be done, right? I have to ask, what's wrong with lazy users? Software which allows you to be lazy gives you a warm tingly feeling, and you install it on your intranet server when no-one's looking. We want people to think of postgresql that way. There are lots of MySQL specific pieces of software out there that started out as some guy/girl with a PHP and MySQL type of book. We can't turn that clock back, but making postgresql easier for the masses has to be a good thing for its adoption. The native win32 port is the poster child for this. It was a big PR win, no? I would argue that leaving autovacuum off is only justifiable if we feel that it's going to be a bad choice for the majority of users. Many of the users who frequent postgresql lists understand the trade-off, but the ones that we're trying to attract don't. Is it better for them to discover manual vacuums when they're trying to incrementally improve performance (with the risk that they never discover them at all), or when their database is running like a dog because they've never vacuumed it at all? One solution might be to turn it on in turn-key solutions: linux distro RPMs, Win32 installer (is it on there already?) etc, but leave it turned off in the source release. Would that help you, or are your clients using RPMs or whatever? Cheers Tom ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Mid cycle release?
On Thu, Sep 14, 2006 at 02:36:22PM -0700, Joshua D. Drake wrote: But on a serious note, the problem I run into is exactly the opposite. Someone will turn on autovacuum because they thought it was a good idea and for their work load, it isn't. So instead of creating new and interesting ways to allow their database to be more efficient, I am dealing with snafu's created by my own community. Then we should change autovacuum so that it stays out of the way when tables are being vacuumed frequently enough via an external means. -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(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] Mid cycle release?
Jim C. Nasby wrote: On Thu, Sep 14, 2006 at 02:36:22PM -0700, Joshua D. Drake wrote: But on a serious note, the problem I run into is exactly the opposite. Someone will turn on autovacuum because they thought it was a good idea and for their work load, it isn't. So instead of creating new and interesting ways to allow their database to be more efficient, I am dealing with snafu's created by my own community. Then we should change autovacuum so that it stays out of the way when tables are being vacuumed frequently enough via an external means. ALTER TABLE foo DISABLE autovacuum? :) 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] Mid cycle release?
Jim C. Nasby [EMAIL PROTECTED] writes: Then we should change autovacuum so that it stays out of the way when tables are being vacuumed frequently enough via an external means. What makes you think it doesn't do that already? Of course, it has its own ideas about what frequently enough is, but it won't re-vacuum a table that's been vacuumed within that interval. While I personally don't really want autovac on in my development environment, I find it hard to deny the argument that it ought to be on by default. If you know enough to set up a cron job to do your own vacuuming schedule, you *certainly* know enough to turn off autovac if you don't want it, or better dial it down to the point where it's just an emergency backstop for your cron job. If you don't know enough to turn off autovac, then you need it on. Also, as noted already, having autovac on by default will encourage the developers to work out the remaining kinks in it ;-) regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Mid cycle release?
Hello, I know that this would be completely out of the norm. However, would it be worth considering having a mid cycle release for 8.3? Basically the release would focus on: Updateable views Bitmap indexes Recursive queries We would release in June? 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] Mid cycle release?
Joshua D. Drake wrote: Hello, I know that this would be completely out of the norm. However, would it be worth considering having a mid cycle release for 8.3? Basically the release would focus on: Updateable views Bitmap indexes Recursive queries We would release in June? Interesting idea but we already have one of the fastest release cycles of all database systems and some people would like to see a larger cycle. In addition to that this plan might hold back some people from upgrading to 8.2 which solves quite a few critical issues with features we marketed/introduced during the past 8.x cycles and are really getting polished and usable now (partitioning,pitr,...) and 8.2 gives quite a nice performance boost for a lot of workloads too. On a personal note - while those features might be nice to market for some of use others would like to see very different things (like proper encoding/character set/collation support or plan invalidation). That might lead to a more that and this feature must be in based release cycle which might not work out that well in practise ... Stefan ---(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] Mid cycle release?
Stefan Kaltenbrunner wrote: Joshua D. Drake wrote: Hello, I know that this would be completely out of the norm. However, would it be worth considering having a mid cycle release for 8.3? Basically the release would focus on: Updateable views Bitmap indexes Recursive queries We would release in June? Interesting idea but we already have one of the fastest release cycles of all database systems and some people would like to see a larger cycle. I really don't care about other database systems. I care about postgresql :). That is also why I wanted to limit the features set specifically. In addition to that this plan might hold back some people from upgrading to 8.2 which solves quite a few critical issues with features we marketed/introduced during the past 8.x cycles and are really getting polished and usable now (partitioning,pitr,...) and 8.2 gives quite a nice performance boost for a lot of workloads too. I frankly won't see many people migrate to 8.2. Most of my customers will wait for 8.3 anyway. (except new business of course). 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] Mid cycle release?
Joshua D. Drake wrote: Stefan Kaltenbrunner wrote: Joshua D. Drake wrote: Hello, I know that this would be completely out of the norm. However, would it be worth considering having a mid cycle release for 8.3? Basically the release would focus on: Updateable views Bitmap indexes Recursive queries We would release in June? Interesting idea but we already have one of the fastest release cycles of all database systems and some people would like to see a larger cycle. I really don't care about other database systems. I care about postgresql :). That is also why I wanted to limit the features set specifically. hmm yeah but as I said - probably not everybody has an immediate demand or is so fixated on those .. In addition to that this plan might hold back some people from upgrading to 8.2 which solves quite a few critical issues with features we marketed/introduced during the past 8.x cycles and are really getting polished and usable now (partitioning,pitr,...) and 8.2 gives quite a nice performance boost for a lot of workloads too. I frankly won't see many people migrate to 8.2. Most of my customers will wait for 8.3 anyway. (except new business of course). I disagree - 8.2 is much more attractive for us then say 8.0 or 8.1 was and we will probably adopt it rather aggressively ... Stefan ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Mid cycle release?
In addition to that this plan might hold back some people from upgrading to 8.2 which solves quite a few critical issues with features we marketed/introduced during the past 8.x cycles and are really getting polished and usable now (partitioning,pitr,...) and 8.2 gives quite a nice performance boost for a lot of workloads too. I frankly won't see many people migrate to 8.2. Most of my customers will wait for 8.3 anyway. (except new business of course). I disagree - 8.2 is much more attractive for us then say 8.0 or 8.1 was and we will probably adopt it rather aggressively ... That's why I said I frankly won't. I have customers with multi terrabyte datasets. 8.1 performs wonderfully for them. It would be a hard push to initiate an 8.2 outage for that. Joshua D. Drake Stefan ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- === 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] Mid cycle release?
Joshua D. Drake wrote: In addition to that this plan might hold back some people from upgrading to 8.2 which solves quite a few critical issues with features we marketed/introduced during the past 8.x cycles and are really getting polished and usable now (partitioning,pitr,...) and 8.2 gives quite a nice performance boost for a lot of workloads too. I frankly won't see many people migrate to 8.2. Most of my customers will wait for 8.3 anyway. (except new business of course). I disagree - 8.2 is much more attractive for us then say 8.0 or 8.1 was and we will probably adopt it rather aggressively ... That's why I said I frankly won't. I have customers with multi terrabyte datasets. 8.1 performs wonderfully for them. It would be a hard push to initiate an 8.2 outage for that. maybe - we have mostly OLTP style databases in the 2-3 figure gigabyte range and none of the features you want to see an entire major release done for would be a reason to upgrade for us. Things 30% overall performance increase for a large set of queries (in our apps) due to planner improvements and things like restartable recovery and reduced dump restore times (due to the sorting fixes) however are :-) Point I want to make is - all those are cool features(and might be critical for some) but I don't think they warrant a dramatic change in the release cycle policy ... Stefan ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Mid cycle release?
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: Point I want to make is - all those are cool features(and might be critical for some) but I don't think they warrant a dramatic change in the release cycle policy ... Any release is going to have some things that are compelling and some that aren't, for any particular person ... it's just that those things vary depending on who you are ... I was heard to gripe not long ago that feature freeze during August was bad timing. It would be interesting to try to do it during the spring instead, just to see if people have more free time then. So for me, +1 for a shorter-than-a-year cycle this time, independently of what features make it or don't. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Mid cycle release?
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: Point I want to make is - all those are cool features(and might be critical for some) but I don't think they warrant a dramatic change in the release cycle policy ... Any release is going to have some things that are compelling and some that aren't, for any particular person ... it's just that those things vary depending on who you are ... no doubt on that :-) I was heard to gripe not long ago that feature freeze during August was bad timing. It would be interesting to try to do it during the spring instead, just to see if people have more free time then. So for me, +1 for a shorter-than-a-year cycle this time, independently of what features make it or don't. well that is something I can agree too - it is mostly the do a special release for exactly those 3 features I don't like that much ... Stefan ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Mid cycle release?
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: Point I want to make is - all those are cool features(and might be critical for some) but I don't think they warrant a dramatic change in the release cycle policy ... Any release is going to have some things that are compelling and some that aren't, for any particular person ... it's just that those things vary depending on who you are ... I was heard to gripe not long ago that feature freeze during August was bad timing. It would be interesting to try to do it during the spring instead, just to see if people have more free time then. So for me, +1 for a shorter-than-a-year cycle this time, independently of what features make it or don't. Well on that same vein (with a +1), I know that we lost at least 8 weeks of productivity from various vacations etc.. during the summer. When you incorporate everyone else that is involved with postgresql, I could easily see almost a full man year lost, by having freeze where it is now. I think having a freeze more toward march/april makes a heck of a lot of sense. Joshua D. Drake regards, tom lane -- === 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] Mid cycle release?
* Joshua D. Drake ([EMAIL PROTECTED]) wrote: Updateable views Bitmap indexes Recursive queries We would release in June? Could we get autovacuum enabled by default too? Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Mid cycle release?
Stephen Frost wrote: * Joshua D. Drake ([EMAIL PROTECTED]) wrote: Updateable views Bitmap indexes Recursive queries We would release in June? Could we get autovacuum enabled by default too? I certainly hope not... I don't really feel like turning it off all the time. Joshua D. Drake Thanks, Stephen -- === 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] Mid cycle release?
* Joshua D. Drake ([EMAIL PROTECTED]) wrote: Stephen Frost wrote: * Joshua D. Drake ([EMAIL PROTECTED]) wrote: Updateable views Bitmap indexes Recursive queries We would release in June? Could we get autovacuum enabled by default too? I certainly hope not... I don't really feel like turning it off all the time. The change had been put into CVS at one point as a pretty-much agreed-upon thing to do, aiui. It was removed mainly because it caused problems for the regression tests which were enough that it was going to take a while to fix them all so the change was postponed to 8.3... Quite a few people (myself included) had really been hoping to see it in 8.2 and it's been the going-forward plan ever since autovacuum was put into the backend (in fact, iirc, having it in the backend was a prerequisite to having it on by default). Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Mid cycle release?
Quite a few people (myself included) had really been hoping to see it in 8.2 and it's been the going-forward plan ever since autovacuum was put into the backend (in fact, iirc, having it in the backend was a prerequisite to having it on by default). w00t, more processes doing things they shouldn't be doing, but doing them automatically at times when they shouldn't be done because of some arbitrary calculation that really isn't documented that well in some conf file! O.k. that was negative, sorry. Frankly I think that turning autovacuum on by default pretty much equates to, I am lazy, and I don't want to actually evaluate my needs. Lets just go with MS Access Joshua D. Drake Thanks, Stephen -- === 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] Mid cycle release?
O.k. that was negative, sorry. Frankly I think that turning autovacuum on by default pretty much equates to, I am lazy, and I don't want to actually evaluate my needs. Lets just go with MS Access Please ignore my negativity today. I apologize. I do not want autovacuum turned on by default but it isn't that big of a deal. Take care. Joshua D. Drake Joshua D. Drake Thanks, Stephen -- === 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] Mid cycle release?
* Joshua D. Drake ([EMAIL PROTECTED]) wrote: w00t, more processes doing things they shouldn't be doing, but doing them automatically at times when they shouldn't be done because of some arbitrary calculation that really isn't documented that well in some conf file! I'd love for it to be improved. If you've got specific suggestions on improvments which could be made then please bring them up on the list. In general I've been reasonably happy with it and it *is* improving as people work on it. Having it enabled by default may get more people interested in improving it too. O.k. that was negative, sorry. Frankly I think that turning autovacuum on by default pretty much equates to, I am lazy, and I don't want to actually evaluate my needs. Lets just go with MS Access It would be kind of nice to have internal database processes, you know, handled *internally*. While autovacuum might not be configured perfectly for a given situation at the outset in the ideal world it would be able to essentially self-configure itself over time. There have been ideas floated to get us closer to that such as the dead-tuple (or dead-page?) list. Unfortunately I'm not really keen on the we use MVCC internally, and MVCC needs it, therefore you as the admin have to deal with it argument. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Mid cycle release?
Stefan Kaltenbrunner wrote: Interesting idea but we already have one of the fastest release cycles of all database systems and some people would like to see a larger cycle. I think the key complaint is about how painful the upgrade process is and if you still get fixes for previous releases if you are not willing to make the big jump. regards, Lukas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Mid cycle release?
No one would expect Oracle to install Oracle and walk away. We are not MySQL, nor MS Access. I can definitely see where you're coming from, it's a sort of tough-love scenario. There are legitimate counter arguments, though. The most obvious is that anyone who *does* evaluate their needs properly shouldn't have too much trouble turning it off, whereas there are lots of small database users out there who find having to set up a vacuum cron a pain. Example: I'm in the process of setting up a typo blog, using postgresql of course, but the database setup was secondary to the main thing that I was doing, and I'd completely forgotten about setting up a cron. Now I'm unlikely to produce blog posts at a rate that will cause the database to grow out of the minuscule range, but it should still be done, right? I have to ask, what's wrong with lazy users? Software which allows you to be lazy gives you a warm tingly feeling, and you install it on your intranet server when no-one's looking. We want people to think of postgresql that way. There are lots of MySQL specific pieces of software out there that started out as some guy/girl with a PHP and MySQL type of book. We can't turn that clock back, but making postgresql easier for the masses has to be a good thing for its adoption. The native win32 port is the poster child for this. It was a big PR win, no? I would argue that leaving autovacuum off is only justifiable if we feel that it's going to be a bad choice for the majority of users. Many of the users who frequent postgresql lists understand the trade-off, but the ones that we're trying to attract don't. Is it better for them to discover manual vacuums when they're trying to incrementally improve performance (with the risk that they never discover them at all), or when their database is running like a dog because they've never vacuumed it at all? One solution might be to turn it on in turn-key solutions: linux distro RPMs, Win32 installer (is it on there already?) etc, but leave it turned off in the source release. Would that help you, or are your clients using RPMs or whatever? Cheers Tom -- === 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] Mid cycle release?
Joshua D. Drake wrote: No one would expect Oracle to install Oracle and walk away. We are not MySQL, nor MS Access. Then why are you complaining about having to disable autovacuum after each installation? It may just be me, but I see as a lot easier to disable autovacuum than to write the necessary cron jobs if it's disabled. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Mid cycle release?
Joshua D. Drake wrote: No one would expect Oracle to install Oracle and walk away. We are not MySQL, nor MS Access. And thank goodness for that! Tom ---(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] Mid cycle release?
Tom Dunstan wrote: Joshua D. Drake wrote: No one would expect Oracle to install Oracle and walk away. We are not MySQL, nor MS Access. And thank goodness for that! Hah! I knew you would eventually agree with me. ;) Joshua D. Drake Tom ---(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 -- === 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] Mid cycle release?
Alvaro Herrera wrote: Joshua D. Drake wrote: No one would expect Oracle to install Oracle and walk away. We are not MySQL, nor MS Access. Then why are you complaining about having to disable autovacuum after each installation? Because my hands hurt and I can't find my gloves. My back hurts (see the previous post about 135mph car crash), I have a huge headache and I am in a generally pissy mood. I am human, I am allowed :) But on a serious note, the problem I run into is exactly the opposite. Someone will turn on autovacuum because they thought it was a good idea and for their work load, it isn't. So instead of creating new and interesting ways to allow their database to be more efficient, I am dealing with snafu's created by my own community. Leaving autovacuum on will cement the idea that it *should* be on and IMHO it shouldn't without specific and careful planning. Sincerely, Joshua D. Drake It may just be me, but I see as a lot easier to disable autovacuum than to write the necessary cron jobs if it's disabled. -- === 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] Mid cycle release?
[EMAIL PROTECTED] (Joshua D. Drake) writes: Leaving autovacuum on will cement the idea that it *should* be on and IMHO it shouldn't without specific and careful planning. For the completely naive user, it seems to me that it *should* be on, as that will diminish the number of questions that we need to answer with Have you ever run VACUUM ANALYZE? -- output = reverse(gro.mca @ enworbbc) http://linuxdatabases.info/info/lsf.html Rules of the Evil Overlord #60. My five-year-old child advisor will also be asked to decipher any code I am thinking of using. If he breaks the code in under 30 seconds, it will not be used. Note: this also applies to passwords. http://www.eviloverlord.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Mid cycle release?
On Thursday 14 September 2006 14:16, Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Point I want to make is - all those are cool features(and might be
critical for some) but I don't think they warrant a dramatic change in
the release cycle policy ...
Any release is going to have some things that are compelling and some
that aren't, for any particular person ... it's just that those things
vary depending on who you are ...
I was heard to gripe not long ago that feature freeze during August was
bad timing. It would be interesting to try to do it during the spring
instead, just to see if people have more free time then. So for me,
+1 for a shorter-than-a-year cycle this time, independently of what
features make it or don't.
Any chance we could enforce a no changes to file formats on this extra-quick
release? Otherwise I have to agree with Joshua, I'll be recommending against
upgrading to 8.2 on any significantly sized databases.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Mid cycle release?
On Thursday 14 September 2006 17:36, Joshua D. Drake wrote:
But on a serious note, the problem I run into is exactly the opposite.
Someone will turn on autovacuum because they thought it was a good idea
and for their work load, it isn't. So instead of creating new and
interesting ways to allow their database to be more efficient, I am
dealing with snafu's created by my own community.
Leaving autovacuum on will cement the idea that it *should* be on and
IMHO it shouldn't without specific and careful planning.
Clearly it's better to have auto-vacuum on than to do nothing, so why not give
our users a better starting position if we can? Otherwise why are we doing
things like attempting to auto-set options in the conf file based on system
specs?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Mid cycle release?
On Thu, 14 Sep 2006, Joshua D. Drake wrote: Well on that same vein (with a +1), I know that we lost at least 8 weeks of productivity from various vacations etc.. during the summer. When you incorporate everyone else that is involved with postgresql, I could easily see almost a full man year lost, by having freeze where it is now. I think having a freeze more toward march/april makes a heck of a lot of sense. Not against the idea ... would push more for March freeze though ... that way admins can plan for upgrades over their 'slow summer months' ... March would effectively look at a June 1st (-ish) release, so even a bit of a slip would still see it as the summer starts ... 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 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
