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

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/

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 solutions since 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 solutions since 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 solutions since 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 solutions since 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 solutions since 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 solutions since 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

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 solutions since 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 solutions since 1997
http://www.commandprompt.com/