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-08 02:41:50
Message-ID: 003201cf0c1b$2eee6760$8ccb3620$@etsuro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas wrote:
> On Mon, Jan 6, 2014 at 9:40 PM, Etsuro Fujita
<fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
> wrote:
> > 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():

> 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?

No. I intended to show the desired memory space for a TIDBitmap rather than
the peak memory usage for that TIDBitmap. And I thought it'd be better for
the latter to be displayed as additional information. However, I've removed
the functionality for showing the desired memory space due to technical
problems. Now I should probably remove the functionality for showing the
peak memory usage too.

Yes, as Andres mentioned, showing the peak memory usage is not a bad idea, I
think. But I start to think it's not necessarily worth complicating the
code ...

If there are no objections of others, I'll remove extra accounting for
showing the peak memory usage.

Thanks,

Best regards,
Etsuro Fujita

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-01-08 02:49:22 Re: WITHIN GROUP patch
Previous Message Tom Lane 2014-01-08 00:51:28 Re: WITHIN GROUP patch