On Tue, 11 Feb 2003, Rick Gigger wrote: > The type of person who can't configure it or doesnt' think to try is > probably not doing a project that requires any serious performance. As long > as you are running it on decent hardware postgres will run fantastic for > anything but a very heavy load. I think there may be many people out there > who have little experience but want an RDBMS to manage their data. Those > people need something very, very easy. Look at the following that mysql > gets despite how poor of a product it is. It's very, very easy. Mysql > works great for many peoples needs but then when they need to do something > real they need to move to a different database entirely. I think there is a > huge advantage to having a product that can be set up very quickly out of > the box. Those who need serious performance, hopefully for ther employers > sake, will be more like to take a few minutes to do some quick performance > tuning.
Very good point. I'm pushing for changes that will NOT negatively impact joe beginner on the major platforms (Linux, BSD, Windows) in terms of install. I figure anyone installing on big iron already knows enough about their OS we don't have to worry about shared buffers being too big for that machine. So, a compromise of faster performance out of the box, with little or no negative user impact seems the sweet spot here. I'm thinking a good knee setting for each one, where not too much memory / semaphores / file handles get gobbled up, but the database isn't pokey. The poor performance of Postgresql in it's current default configuration HAS cost us users, trust me, I know a few we've almost lost where I work that I converted after some quick tweaking of their database. In it's stock form Postgresql is very slow at large simple queries, like 'select * from table1 t1 natural join table2 t2 where t1.field='a'; where you get back something like 10,000 rows. The real bottleneck here is sort_mem. A simple bump up to 8192 or so makes the database much more responsive. If we're looking at changing default settings for 7.4, then we should look at changing ALL of them that matter, since we'll have the most time to shake out problems if we do them early, and we won't have four or five rounds of setting different defaults over time and finding the limitations of the HOST OSes one at a time. ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html