On Mon, Jan 6, 2014 at 9:40 PM, Etsuro Fujita
<fujita.etsuro@lab.ntt.co.jp> wrote:
> Robert Haas wrote:
>> I spent some time looking at this tonight. I don't think the value that
>> is displayed for the bitmap memory tracking will be accurate in complex
>> cases. The bitmap heap scan may sit on top of one or more bitmap-and or
>> bitmap-or nodes. When a bitmap-and operation happens, one of the two
>> bitmaps being combined will be thrown out and the number of entries in the
>> other map will, perhaps, be decreased. The peak memory usage for the
>> surviving bitmap will be reflected in the number displayed for the bitmap
>> heap scan, but the peak memory usage for the discarded bitmap will not.
>> This is wholly arbitrary because both bitmaps existed at the same time,
>> side by side, and which one we keep and which one we throw out is
> essentially
>> random.
>
> Thank you for taking time to look at this patch. The peak memory usage for
> the discarded bitmap *can* be reflected in the number displayed for the
> bitmap heap scan by the following code in tbm_union() or tbm_intersect():
>
> tbm_union(TIDBitmap *a, const TIDBitmap *b)
> {
> Assert(!a->iterating);
> + if (a->nentriesPeak < b->nentriesPeak)
> + a->nentriesPeak = b->nentriesPeak;
> /* Nothing to do if b is empty */
> if (b->nentries == 0)
> return;
> ***************
>
> tbm_intersect(TIDBitmap *a, const TIDBitmap *b)
> {
> Assert(!a->iterating);
> + if (a->nentriesPeak < b->nentriesPeak)
> + a->nentriesPeak = b->nentriesPeak;
> /* Nothing to do if a is empty */
> if (a->nentries == 0)
> return;
> ***************
>
> Sorry for the delay.
Hmm, fair point. But I'm still not convinced that we really need to
add extra accounting for this. What's wrong with just reporting the
number of exact and lossy pages?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
