Re: Seqscan rather than Index

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Seqscan rather than Index
Дата
Msg-id 87acsdkjte.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Re: Seqscan rather than Index  (Richard Huxton <dev@archonet.com>)
Ответы Re: Seqscan rather than Index  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Seqscan rather than Index  ("Steinar H. Gunderson" <sgunderson@bigfoot.com>)
Список pgsql-performance
Richard Huxton <dev@archonet.com> writes:

> Not going to do anything in this case. The planner is roughly right about how
> many rows will be returned, it's just not expecting everything to be in RAM.

That doesn't make sense or else it would switch to the index at
random_page_cost = 1.0. If it was still using a sequential scan at
random_page_cost < 1 then perhaps he had some problem with his query like
mismatched data types that forced it to use a full scan.

> > That's the standard advice around here and the only thing I've found
> > useful. Half the threads in this forum are about under-utilized
> > indexes. It would be great if someone could admit the planner is
> > broken and talk about actually fixing it!
>
> Not sure I agree here - when the stats are accurate, you can get the planner to
> make near-optimal choices most of the time. Is there any particular pattern
> you've seen?

The most common cause I've seen here is that Postgres makes very pessimistic
assumptions about selectivity when it doesn't know better. Every other
database I've tested assumes 'col > ?' is about 5% selectivity . Postgres
assumes 33%.

Postgres is also more pessimistic about the efficiency of index scans. It's
willing to use a sequential scan down to well below 5% selectivity when other
databases use the more traditional rule of thumb of 10%.

In combination these effects do seem to cause an _awful_ lot of complaints.


> > The issue hits PostgreSQL harder than others because of its awful
> > sequential scan speed, which is two to five times slower than other
> > DBMS. The archives show there has been talk for years about this, but
> > it seems, no solution. The obvious thing to consider is the block
> > size, but people have tried increasing this in the past with only
> > marginal success.
>
> Must admit this puzzles me. Are you saying you can't saturate your disk I/O? Or
> are you saying other DBMS store records in 0.5 to 0.2 times less space than PG?

I don't know what he's talking about either. Perhaps he's thinking of people
who haven't been running vacuum enough?

--
greg

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

Предыдущее
От: Richard Huxton
Дата:
Сообщение: Re: Seqscan rather than Index
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Seqscan rather than Index