Re: [HACKERS] Proposal: Improve bitmap costing for lossy pages

Поиск
Список
Период
Сортировка
От Dilip Kumar
Тема Re: [HACKERS] Proposal: Improve bitmap costing for lossy pages
Дата
Msg-id CAFiTN-s85n6A_w_WoGAtwT+vcv8y0+2RuSx6niOQUP092HFwNA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Proposal: Improve bitmap costing for lossy pages  (Alexander Kuzmenkov <a.kuzmenkov@postgrespro.ru>)
Ответы Re: [HACKERS] Proposal: Improve bitmap costing for lossy pages  (Dilip Kumar <dilipbalaut@gmail.com>)
Список pgsql-hackers
On Fri, Oct 6, 2017 at 6:08 PM, Alexander Kuzmenkov
<a.kuzmenkov@postgrespro.ru> wrote:
>
>> Analysis: The estimated value of the lossy_pages is way higher than
>> its actual value and reason is that the total_pages calculated by the
>> "Mackert and Lohman formula" is not correct.
>
>
> I think the problem might be that the total_pages includes cache effects and
> rescans. For bitmap entries we should use something like relation pages *
> selectivity.

I have noticed that for the TPCH case if I use "pages * selectivity"
it give me better results, but IMHO directly multiplying the pages
with selectivity may not be the correct way to calculate the number of
heap pages it can only give the correct result when all the TID being
fetched are clustered.  But on the other hand "Mackert and Lohman
formula" formulae consider that all the TID's are evenly distributed
across the heap pages which can also give the wrong estimation like we
are seeing in our TPCH case.

>
> Meanwhile, I ran TPC-H briefly with the v3 patch: scale factor 25, 2
> workers, SSD storage.
> It shows significant improvement on 4MB work_mem and no change on 2GB.
>
> Here are the results (execution time in seconds, average of 5 runs):
> work_mem    4MB                2GB
> Query     master    patch    master    patch
> 4        179        174        168        167
> 5        190        168        155        156
> 6        280        87        227        229
> 8        197        114        179        172
> 10        269        227        190        192
> 14        110        108        106        105
>

Thanks for the testing number looks good to me.


-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updatedtuple