Re: SELECT's take a long time compared to other DBMS
От | Christopher Browne |
---|---|
Тема | Re: SELECT's take a long time compared to other DBMS |
Дата | |
Msg-id | m3ad9l6y11.fsf@chvatal.cbbrowne.com обсуждение исходный текст |
Ответ на | SELECT's take a long time compared to other DBMS ("Relaxin" <me@yourhouse.com>) |
Список | pgsql-performance |
Quoth "Relaxin" <me@yourhouse.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="acm.org" in name ^ "@" ^ tld;; http://cbbrowne.com/info/oses.html "Computers let you make more mistakes faster than any other invention in human history, with the possible exception of handguns and tequila." -- Mitch Radcliffe
В списке pgsql-performance по дате отправления: