Re: speed 6.5 vs 7.0

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: speed 6.5 vs 7.0
Дата
Msg-id 5088.960935474@sss.pgh.pa.us
обсуждение исходный текст
Ответ на speed 6.5 vs 7.0  (Jeff MacDonald <jeff@pgsql.com>)
Список pgsql-hackers
Jeff MacDonald <jeff@pgsql.com> writes:
> now is it just me or is the cost on the dualpIII450 a little out of wack ?

You seem to be confusing EXPLAIN's cost numbers with reality ;-)

The EXPLAIN numbers are on an arbitrary scale that is only used to
measure the relative costs of different plans, so there's no attempt
to adjust it for the actual speed of different machines.  Given
identical Postgres versions, databases, and queries, you should get
identical EXPLAIN results no matter what hardware you're using.

The difference that you see here is entirely due to the differences
between the 6.5 and 7.0 cost estimators, and basically the answer is
that the 6.5 estimator is broken.  It's crediting the indexscan with
the selectivity of the whole WHERE clause, when in reality the only part
that the index can exploit is "gender = 0".  So although there may be
few tuples returned by the query, the indexscan will have to scan a lot
of tuples and hence should have a pretty high cost.

I'm actually pretty surprised that 7.0 will use an indexscan in
this situation at all.  Making the (perhaps incorrect?) assumption
that "gender = 0" selects about half the tuples, a plain sequential
scan ought to be faster.  Have you done a VACUUM ANALYZE on this table?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Compiler error with libpq++
Следующее
От: "G. Anthony Reina"
Дата:
Сообщение: 7.0.2 cuts off attribute name