From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
---|---|
To: | Alexander Kumenkov <a(dot)kuzmenkov(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: Improve bitmap costing for lossy pages |
Date: | 2017-08-23 04:15:35 |
Message-ID: | CAFiTN-vZRrBBNSS1XZZOX-B_anGVMVay-s=dUgHHMQkTYNKZ-w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 22, 2017 at 8:40 PM, Alexander Kumenkov
<a(dot)kuzmenkov(at)postgrespro(dot)ru> wrote:
> Hi Dilip,
>
> Recently I was thinking about this too, when working on the index-only
> count(*) patch for indexes supporting amgetbitmap [1]. That patch teaches
> bitmap heap scan node to skip heap fetches under certain conditions. Exact
> tidbitmap pages are a prerequisite for this, so the lossines of the bitmap
> heavily influences the cost of a scan.
>
> I used a very simple estimation: lossy_pages = max(0, total_pages -
> maxentries / 2). The rationale is that after the initial lossification, the
> number of lossy pages grows slower. It is good enough to reflect this
> initial sharp increase in the lossy page number.
Make sense to me.
>
> The thing that seems more important to me here is that the tidbitmap is very
> aggressive in lossifying the pages: it tries to keep the number of entries
> under maxentries / 2, see tbm_lossify():
> ...
> if (tbm->nentries <= tbm->maxentries / 2)
> {
> /*
> * We have made enough room.
> ...
> I think we could try higher fill factor, say, 0.9. tbm_lossify basically
> just continues iterating over the hashtable with not so much overhead per a
> call, so calling it more frequently should not be a problem. On the other
> hand, it would have to process less pages, and the bitmap would be less
> lossy.
>
> I didn't benchmark the index scan per se with the 0.9 fill factor, but the
> reduction of lossy pages was significant.
I will try this and produce some performance number.
Thanks for the input.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Haribabu Kommi | 2017-08-23 05:26:03 | Re: Pluggable storage |
Previous Message | Masahiko Sawada | 2017-08-23 01:59:40 | Re: Explicit relation name in VACUUM VERBOSE log |