From: | "Tomi N/A" <hefest(at)gmail(dot)com> |
---|---|
To: | "Scott Marlowe" <smarlowe(at)g2switchworks(dot)com> |
Cc: | "pgsql general" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Speed of postgres compared to ms sql, is this |
Date: | 2006-12-06 02:13:32 |
Message-ID: | d487eb8e0612051813u2fbd8cbdq4f7d1b81b9acd62b@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
2006/12/5, Scott Marlowe <smarlowe(at)g2switchworks(dot)com>:
> On Tue, 2006-12-05 at 16:32, Tomi N/A wrote:
>
> > One type of query does come to mind, now that I think about it.
> > pgsql has trouble handling queries like
> > SELECT * FROM t0 WHERE t0.id_t1 IN (SELECT t1.id FROM t1 WHERE...)
>
> > When the subselect returns a lot of results, pgsql really takes it's time.
>
> Just wondering what version of pgsql you were using, as the in()
> performance has been greatly improved in the newer versions.
8.1.something
> What I noticed was that PostgreSQL was better under parallel load than
> MSSQL server was. Our pgsql 7.2 server would routinely outrun the MSSQL
> server (This was like 3 years ago) when they were both moderately
> loaded. Of course, we didn't run a lot of where in () queries on the
> pgsql server, we re-worked them to favor postgresql's query planner of
> the time.
We frequently run into the same basic RDBMS benchmarking problem:
basically any database can be fastest in a given context, depending on
how the query is expressed and what it does.
Cheers,
t.n.a.
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Broersma Jr | 2006-12-06 05:48:22 | 8.2 contrib. "Full Disjunction" |
Previous Message | Nathan Boley | 2006-12-06 01:01:39 | Update Perrformance with nested loop vs. merge-join |