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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
