Re: slow full table update

Поиск
Список
Период
Сортировка
От Vladimir Sitnikov
Тема Re: slow full table update
Дата
Msg-id 1d709ecc0811120958k5be6235vc3dbeb6fb58f4a68@mail.gmail.com
обсуждение исходный текст
Ответ на Re: slow full table update  (Richard Huxton <dev@archonet.com>)
Список pgsql-performance
Дерево обсуждения

>
>   Recheck Cond: ((sid > 20000) AND (sid < 30000))
>
>   ->  Bitmap Index Scan on pk_songs2  (cost=0.00..151.59 rows=8931 width=0) (actual time=4.071..4.071 rows=9579 loops=1)
>
>         Index Cond: ((sid > 20000) AND (sid < 30000))
>
> Is there a way to run this query on sigle  throughpass with no Recheck Cond?

"Recheck Cond" is somewhat misleading here.
 
Bitmap Index Scan has almost void "recheck" impact in case the whole bitmap fits in work_mem. That means bitmap scan degrades when the number of rows in table (not the total number of returned rows) is greater than work_mem*1024*8. 60'000 rows bitmap scan will require 60'000/8=7'500 bytes ~ 8Kbytes of memory to run without additional recheck, thus I do not believe it hurts you in this particular case


Regards,
Vladimir Sitnikov

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

Предыдущее
От: Richard Huxton
Дата:
Сообщение: Re: slow full table update
Следующее
От: "Andrus"
Дата:
Сообщение: Re: Increasing select max(datecol) from bilkaib where datecol<=date'2008-11-01' and (cr='00' or db='00') speed