Re: Choice of bitmap scan over index scan

Поиск
Список
Период
Сортировка
От Mathieu De Zutter
Тема Re: Choice of bitmap scan over index scan
Дата
Msg-id d4468d971001110036s22796d2bud01f8ec38fd21ce0@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Choice of bitmap scan over index scan  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Choice of bitmap scan over index scan  (Matthew Wakeling <matthew@flymine.org>)
Re: Choice of bitmap scan over index scan  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список pgsql-performance
On Mon, Jan 11, 2010 at 3:52 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Sun, Jan 10, 2010 at 10:53 AM, Kevin Grittner
> seq_page_cost = 0.1
> random_page_cost = 0.1

These might not even be low enough.  The reason why bitmap index scans
win over plain index scans, in general, is because you make one pass
through the heap to get all the rows you need instead of bouncing
around doing lots of random access.  But of course if all the data is
in RAM then this argument falls down.

If these aren't enough to get the query planner to DTRT, then the OP
might want to try lowering them further and seeing how low he has to
go to flip the plan...
 
So if this query usually does *not* hit the cache, it will be probably faster if I leave it like that? While testing a query I execute it that much that it's always getting into the cache. However, since other applications run on the same server, I think that infrequently used data gets flushed after a while, even if the DB could fit in the RAM.

--
Mathieu

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Choice of bitmap scan over index scan
Следующее
От: Matthew Wakeling
Дата:
Сообщение: Re: Choice of bitmap scan over index scan