Re: Show lossy heap block info in EXPLAIN ANALYZE for bitmap heap scan

From: "Etsuro Fujita" <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: "'Robert Haas'" <robertmhaas(at)gmail(dot)com>
Cc: "'Amit Khandekar'" <amit(dot)khandekar(at)enterprisedb(dot)com>, "'pgsql-hackers'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Show lossy heap block info in EXPLAIN ANALYZE for bitmap heap scan
Date: 2014-01-07 02:40:32
Message-ID: 01c401cf0b51$d60ebba0$822c32e0$@etsuro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Best regards,
Etsuro Fujita

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Johnston 2014-01-07 02:52:53 Re: Fixing bug #8228 ("set-valued function called in context that cannot accept a set")
Previous Message Hafez Kamal 2014-01-07 02:37:05 [HITB-Announce] HITB Magazine Issue 10 Out Now