Skip site navigation (1) Skip section navigation (2)

Re: SELECT's take a long time compared to other DBMS

From: Christopher Browne <cbbrowne(at)acm(dot)org>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: SELECT's take a long time compared to other DBMS
Date: 2003-09-04 03:19:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Quoth "Relaxin" <me(at)yourhouse(dot)com>:
> Yes I Analyze also, but there was no need to because it was a fresh
> brand new database.

That is _absolutely not true_.

It is not true with any DBMS that uses a cost-based optimizer.
Cost-based optimizers need some equivalent to ANALYZE in order to
collect statistics to allow them to pick any path other than a
sequential scan.

In this particular case, a seq scan is pretty likely to be the best
answer when there is no WHERE clause on the query.

Actually, it doesn't make all that much sense that the other systems
would be terribly much faster, because they obviously need to do some
processing on 102,384 records.

Can you tell us what you were *actually* doing?  Somehow it sounds as
though the other databases were throwing away the data whereas
PostgreSQL was returning it all "kawhump!" in one batch.

What programs were you using to submit the queries?
let name="cbbrowne" and tld="" in name ^ "@" ^ tld;;
"Computers let you make more  mistakes faster than any other invention
in  human  history,  with  the  possible  exception  of  handguns  and
tequila."  -- Mitch Radcliffe

In response to


pgsql-performance by date

Next:From: Christopher BrowneDate: 2003-09-04 03:24:19
Subject: Re: SELECT's take a long time compared to other DBMS
Previous:From: Federico Sevilla IIIDate: 2003-09-04 03:04:04
Subject: PostgreSQL Reliability when fsync = false on Linux-XFS

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group