From: | "Etsuro Fujita" <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | "'Amit Khandekar'" <amit(dot)khandekar(at)enterprisedb(dot)com> |
Cc: | "'pgsql-hackers'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Show lossy heap block info in EXPLAIN ANALYZE for bitmap heap scan |
Date: | 2013-11-26 08:30:40 |
Message-ID: | 006101ceea81$ca22c480$5e684d80$@etsuro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Amit Khandekar wrote:
> On 25 November 2013 13:37, Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> So, my question is, we should show the number of exact/lossy pages in a
>> TIDBitmap, not the number of these pages that has been fetched in the bitmap
>> heap scan?
> Yes, I agree that rather than looking at the bitmap heap scan to track the
> number of pages, we should look somewhere in the underlying index scan. Yes,
> we should get a constant number of index pages regardless of the actual
> parent table rows. I can see that btgetbitmap() adds all the tuples into the
> bitmap, so somewhere below under btgetbitmap() might be the right place to
> track. Somewhere in tbm_create_pagetable(), but not sure.
Thank you for the comment!
I agree with you. I'll modify the patch to show 1) the number of the exact/lossy pages in a TIDBitmap by examining the underlying index scan, not the number of these pages that have been fetched in the bitmap heap scan, and 2) the memory requirement.
Thanks,
Best regards,
Etsuro Fujita
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2013-11-26 08:48:01 | Re: Extension Templates S03E11 |
Previous Message | Amit Khandekar | 2013-11-26 07:23:49 | Re: Show lossy heap block info in EXPLAIN ANALYZE for bitmap heap scan |