Thread: 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 solutionssince 1997 http://www.commandprompt.com/
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
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 solutionssince 1997 http://www.commandprompt.com/
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
>>> 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 solutionssince 1997 http://www.commandprompt.com/
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
Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> 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
Tom Lane wrote: > Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> 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
Tom Lane wrote: > Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> 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 solutionssince 1997 http://www.commandprompt.com/
* Joshua D. Drake (jd@commandprompt.com) wrote:
> Updateable views
> Bitmap indexes
> Recursive queries
>
> We would release in June?
Could we get autovacuum enabled by default too?
Thanks,
Stephen
Stephen Frost wrote: > * Joshua D. Drake (jd@commandprompt.com) 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 solutionssince 1997 http://www.commandprompt.com/
* Joshua D. Drake (jd@commandprompt.com) wrote:
> Stephen Frost wrote:
> >* Joshua D. Drake (jd@commandprompt.com) 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
> > 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 solutionssince 1997 http://www.commandprompt.com/
> > 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 solutionssince 1997 http://www.commandprompt.com/
* Joshua D. Drake (jd@commandprompt.com) 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
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
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 solutionssince 1997 http://www.commandprompt.com/
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 Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
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
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 majordomo@postgresql.org 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 solutionssince 1997 http://www.commandprompt.com/
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 solutionssince 1997 http://www.commandprompt.com/
jd@commandprompt.com ("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/>
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
On Thursday 14 September 2006 14:16, Tom Lane wrote:
> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> 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
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 . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
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
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 jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
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 solutionssince 1997 http://www.commandprompt.com/
"Jim C. Nasby" <jimn@enterprisedb.com> 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
On Sep 16, 2006, at 9:31 PM, Tom Lane wrote: > "Jim C. Nasby" <jimn@enterprisedb.com> 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 jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
On Thu, 2006-09-14 at 14:16 -0400, Tom Lane wrote: > Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> 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
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 bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +