Re: [CORE] RC1 blocker issues
От | Stefan Kaltenbrunner |
---|---|
Тема | Re: [CORE] RC1 blocker issues |
Дата | |
Msg-id | 456AA6F7.6060503@kaltenbrunner.cc обсуждение исходный текст |
Ответ на | Re: [CORE] RC1 blocker issues ("Joshua D. Drake" <jd@commandprompt.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: