This has been a very interesting thread, if for no other reason then
to just catalog all of the changes going into 8.2. I am going to be
changing some hardware around so I need to decide if I want to a)
change the hardware now and don't bother with 8.2, b) wait to upgrade
hardware and do the upgrade to 8.2 at the same time, c) upgrade the
hardware now and then upgrade to 8.2 when it is released.
What I do basically depends on how much benefit I'm going to get from
8.2 and whether it's worth planning my hardware upgrades around or
incurring additional downtime in order to do the postgres upgrade.
Doing a dump/reload is not a problem at all, it doesn't take that
long with the data I've got. It's just having to kick everyone off
the system and shut everything down in order to do it.
My applications are not that demanding on the DB so there isn't
anything that I "NEED" that postgres doesn't already have. Because
of this I stayed on 7.3 for way, way too long. It just didn't seem
worth the effort to do the upgrade or the additional testing against
each postgres version to make sure it didn't break my apps. But I
finally bit the bullet and upgraded straight to 8.1. I couldn't
believe what a huge performance difference it made even though I
didn't use any of the big headlining features. (ie PITR, two-phase
commit, etc). So I'm sure that even though I don't even understand
what most of the items on toms huge list are, and I certainly don't
understand where they will come into play for me, I'm sure that once
I've upgraded and I use it for a while, I'll be very glad I did.
That being said I think that Bruce has a point in that there is a
certain class of features (which seems hard to define) which existed
in 8.0 and 8.1 but not 8.2. I would define it like this:
A) There are features that PHBs would look for.
B) There are features that a casual database user would look for.
C) There are features that an experienced database user would look
for / understand
D) and then there are features that a database guru/developer of
database software would understand.
Features of class A contribute to the bullet point lists, the buzz
word checklists, etc and are easily used for marketing. For instance
if someone were to package up postgres and put it in a box you would
not have a list of "new features in 8.2!" that included "lazy vacuums
are ignored by other processes". Only an existing postgres user who
has had a setup complex enough to need a tricky vacuuming strategy
would ever even know what that meant much less care about it. It
might be life and death for many users, but it doesn't go on the back
of the box.
So if you define "major features" as class A features. In this case
major doesn't mean important or useful or difficult to implement,
just that they are the sort of features that one might be told to
look for when shopping for a database. So in terms of marketing
PITR, two phase commit, WIN32 support were very much "major" features.
If people had expectations that are not being met it could be because
8.0 and 8.1 had so many of these headlining, market friendly,
buzzword compliant "major" features. It doesn't make it any less
impressive technically or less useful for the actual users of the
database but it DOES make a difference as to how this release will be
perceived by a lot of people. Not that it's a problem, but many
people I think will see this release as less "Major" than the 8.0 or
8.1 releases. I think this is reflected in the fact that 8.0 was
picked as the version to jump up to 8.0 instead of 7.5.
I will upgrade at some point but mostly because experience has taught
me that each release of postgres is significantly better than the
last one, even if I won't see how until I actually use it in production.
That being said I think that two of the not-yet-reviewed features are
just as "major" as the "major" features from the past two releases.
1) updatable views - I won't really use this but it just seems like
one of those features that people use when doing rdbms features
comparison charts. I think that having updatable views will be
considered by the masses to be a "major features"
2) restartable recovery (allow checkpoints for a hot-standby server)
- Having the ability to have a hot standby database is a HUGE feature
in my book. Maybe I'm just biased because it's a feature that I
actually need but I think it's very big. Yes you can sort of do the
same thing or something "better" with slony but this is what I really
want (and I'm guessing that this will get used A LOT if it makes it
in). And it's "bulit in" unlike slony. And it seems much easier to
set up and maintain and less likely to have problems or complicate
things than slony. In terms of having a setup with no "single point
of failure" this goes a long way. And it builds on something that I
will want set up anyway (PITR).
Anyway this is just my $0.02 as a fairly average to low end, user of
postgres as to how this issue may be perceived by the masses.
Thanks in advance for what will certainly be another great release.
On Aug 3, 2006, at 10:46 PM, Bruce Momjian wrote:
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. Again, nothing wrong with that.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDB http://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
---------------------------(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
