Re: Slow query + why bitmap index scan??

От: Kevin Grittner
Тема: Re: Slow query + why bitmap index scan??
Дата: ,
Msg-id: 4D2D68270200002500039327@gw.wicourts.gov
(см: обсуждение, исходный текст)
Ответ на: Re: Slow query + why bitmap index scan??  (Laszlo Nagy)
Ответы: Re: Slow query + why bitmap index scan??  (Laszlo Nagy)
Список: pgsql-performance

Скрыть дерево обсуждения

Slow query + why bitmap index scan??  (Laszlo Nagy, )
 Re: Slow query + why bitmap index scan??  (Florian Weimer, )
  Re: Slow query + why bitmap index scan??  (Laszlo Nagy, )
   Re: Slow query + why bitmap index scan??  (Kenneth Marshall, )
   Re: Slow query + why bitmap index scan??  ("Kevin Grittner", )
    Re: Slow query + why bitmap index scan??  (Laszlo Nagy, )
     Re: Slow query + why bitmap index scan??  ("Kevin Grittner", )
      Re: Slow query + why bitmap index scan??  (Cédric Villemain, )

Laszlo Nagy <> wrote:

> shared_mem = 6GB
> work_mem = 512MB
> total system memory=24GB

In addition to the good advice from Ken, I suggest that you set
effective_cache_size (if you haven't already).  Add whatever the OS
shows as RAM used for cache to the shared_mem setting.

But yeah, for your immediate problem, if you can cluster the table
on the index involved, it will be much faster.  Of course, if the
table is already in a useful order for some other query, that might
get slower, and unlike some other products, CLUSTER in PostgreSQL
doesn't *maintain* that order for the data as new rows are added --
so this should probably become a weekly (or monthly or some such)
maintenance operation.

-Kevin


В списке pgsql-performance по дате сообщения:

От: Cédric Villemain
Дата:
Сообщение: Re: Slow query + why bitmap index scan??
От: Jon Nelson
Дата:
Сообщение: queries with lots of UNIONed relations