Re: [CORE] RC1 blocker issues - Mailing list pgsql-hackers

Joshua D. Drake wrote:
> 
>> 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?

so what ? there is not guarantee that 8.3 _WILL_ be there in that 
timeframe and given that you might not want to jump onto 8.3.0 that 
timeframe could be much longer.

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

well then why even thinking about upgrading to 8.3 or 8.4 or 9.0 or 
whatever ?

> 
> 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.

That is probably not directly dependent on the hardware - creating 
indexes in PostgreSQL is directly dependent on the speed of the single 
CPU doing the building (given you more than a single IDE disk).
If you look back to the thread that caused the massive improvements in 
external sort speed you will see that we are talking something like 12 
hours vs. a bit more then 2 hours for a 1.8B row table on what i think 
was the fastest single core available at that point (2.6Ghz Opteron).
While most tables are much smaller in reality that improvment might 
result in the difference between a "hardly noticable outage" and "real 
downtime" due to the exclusive looking create index requires(and it 
speeds up dump & restore cycles considerably so making upgrades less 
problematic).

> 
> 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.

joins against UNION ALL'd tables are one of the things where 8.2 has 
improved considerably

> 
> 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.

see above - per that logic 8.3 is more then 6 months away for you - and 
there is a year of development in 8.2 fixing a lot of small things that 
might bite(or rather annoy) you (or not *g*) sometime.

> 
> 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.

fair point (and in fact we do the same here) - but your original mail 
made the impression that you are underimpressed by 8.2 which might be 
true for your use cases but as a general statement it is not in my opinion.


Stefan