Re: Perfomance Tuning
От | Josh Berkus |
---|---|
Тема | Re: Perfomance Tuning |
Дата | |
Msg-id | 200308130846.55991.josh@agliodbs.com обсуждение исходный текст |
Ответ на | Re: Perfomance Tuning (Jeff <threshar@torgo.978.org>) |
Ответы |
Re: Perfomance Tuning
Re: Perfomance Tuning Re: Perfomance Tuning |
Список | pgsql-performance |
Jeff, > Informix, etc. have spent a lot of time and money working on it. > They also have the advantage of having many paid fulltime > developers who are doing this for a job, not as a weekend hobby > (Compared to the what? 2-3 full time PG developers). I think 4-6 full-time, actually, plus about 200 part-time contributors. Which adds up to a bloody *lot* of code if you monitor pgsql-patches between versions. The only development advantage the commercials have over us is the ability to engage in large projects (e.g. replication, raw filesystems, etc.) that are difficult for a distributed network of people. > The other advantage (which I hinted to above) with raw disks is being able > to optimize queries to take advantage of it. Informix is multithreaded > and it will spawn off multiple "readers" to do say, a seq scan (and merge > the results at the end). I like this idea. Has it ever been discussed for PostgreSQL? Hmmm .... we'd need to see some tests demonstrating that this approach was still a technical advantage given the improvements in RAID and FS technology since Informix was designed. As I have said elsewhere, Informix is probably a poor database to emulate since they are effectively an old dead-end fork of the Ingres/Postgres code, and have already been "mined" for most of the improvements they made. -- Josh Berkus Aglio Database Solutions San Francisco
В списке pgsql-performance по дате отправления: