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
