Re: [CORE] RC1 blocker issues

> from the testing i have done with some of our production databases - 8.2
> gives a tremendous performance boost (nearly on a similiar scale that
> 7.4->8.1 gave us!). Some of those gains are planner improvments (like
> the out-joins enhancements others seem to come from the improved sorting
> and concurrency. Last but least 8.2 seems to use a bit less of memory
> for some queries too which helps concurrency.
> So I'm a bit surprised that Josh is not considering those as very
> interesting either ...

O.k. hold on... let's be realistic. If I have a 500 Gig database, and I 
know that 8.3 is coming in 6-9 months... why would I migrate to 8.2 with 
8.3 literally right around the corner?

Now take into account that 8.1 works just fine for the customer?

What is my argument?

It's faster? The customer isn't having performance issues... So what's 
the argument?

I can build indexes without an exclusive lock? I am running 75-150k in 
hardware... I build indexes fast anyway.

Constraint exclusion works for updates and deletes? Well that is 
certainly useful, but our major issue was SELECTS and you already built 
out a complete partitioning system.

And frankly, CMD has a standing policy to not push a .0 release. Ever. 
If a customer comes to me and says I have a mission critical system that 
is currently making me *n* amount of dollars an hour, what version of 
PostgreSQL would you suggest? That version will be 8.1.5 until at least 
Feb/March depending on what happens as early adopters pick up.

Again, I am not complaining, nor being negative about 8.2 but I don't 
get the leisure of playing with software. I work with software. That 
means measured, timed and slow migrations to stable releases.

Unfortunately in this case it means that the software may get skipped 
because I know (although the customer likely doesn't) that a new major 
release is due around my birthday.

Sincerely,

Joshua D. Drake