Re: PostgreSQL and Linux 2.6 kernel.
От | Gary Doades |
---|---|
Тема | Re: PostgreSQL and Linux 2.6 kernel. |
Дата | |
Msg-id | 406FDA23.19934.24163F4@localhost обсуждение исходный текст |
Ответ на | Re: PostgreSQL and Linux 2.6 kernel. ("Aaron Werman" <awerman2@hotmail.com>) |
Список | pgsql-performance |
Possibly. A lot of my queries show comparable performance, some a little slower and a few a little faster. There are a few, however, that really grind on PostgreSQL. I am leaning patterns from these to try and and target the most likely performance problems to come and hand tune these types of SQL. I'm not complaining about PostgreSQL or saying that SQLServer is better, in most cases it is not. SQLServer seems to be more predictable and forgiving in performance which tends to make for lazy SQL programming. It also has implications when the SQL is dynamically created based on user input, there are more chances of PostgreSQL hitting a performance problem than SQLServer. Overall I'm still very impressed with PostgreSQL. Given the $7000 per processor licence for SQLServer makes the case for PostgreSQL even stronger! Cheers, Gary. On 3 Apr 2004 at 17:43, Aaron Werman wrote: Almost any cross dbms migration shows a drop in performance. The engine effectively trains developers and administrators in what works and what doesn't. The initial migration thus compares a tuned to an untuned version. /Aaron ----- Original Message ----- From: "Josh Berkus" <josh@agliodbs.com> To: "Gary Doades" <gpd@gpdnet.co.uk>; <pgsql-performance@postgresql.org> Sent: Saturday, April 03, 2004 1:59 PM Subject: Re: [PERFORM] PostgreSQL and Linux 2.6 kernel. > Gary, > > > There are no indexes on the columns involved in the update, they are > > not required for my usual select statements. This is an attempt to > > slightly denormalise the design to get the performance up comparable > > to SQL Server 2000. We hope to move some of our databases over to > > PostgreSQL later in the year and this is part of the ongoing testing. > > SQLServer's query optimiser is a bit smarter that PostgreSQL's (yet) > > so I am hand optimising some of the more frequently used > > SQL and/or tweaking the database design slightly. > > Hmmm ... that hasn't been my general experience on complex queries. However, > it may be due to a difference in ANALYZE statistics. I'd love to see you > increase your default_stats_target, re-analyze, and see if PostgreSQL gets > "smarter". > > -- > -Josh Berkus > Aglio Database Solutions > San Francisco > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Incoming mail is certified Virus Free. Checked by AVG Anti-Virus (http://www.grisoft.com). Version: 7.0.230 / Virus Database: 262.6.5 - Release Date: 31/03/2004
В списке pgsql-performance по дате отправления: