On Thu, Jan 9, 2014 at 10:57 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
I wrote:
Robert Haas wrote:
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
I wrote:
Robert Haas wrote:
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
On Mon, Jan 6, 2014 at 9:40 PM, Etsuro Fujita
fujita.ets...@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
Robert Haas wrote:
On Mon, Jan 6, 2014 at 9:40 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.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
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,
On 2014-01-01 21:15:46 -0500, Robert Haas wrote:
[ sensible reasoning ] However, I'm not sure it's really worth it.
I think what people really care about is knowing whether the bitmap
lossified or not, and generally how much got lossified. The counts of
exact and lossy pages are sufficient
On Thu, Jan 2, 2014 at 4:27 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-01-01 21:15:46 -0500, Robert Haas wrote:
[ sensible reasoning ] However, I'm not sure it's really worth it.
I think what people really care about is knowing whether the bitmap
lossified or not, and generally
On Fri, Dec 27, 2013 at 1:47 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
I wrote:
Robert Haas wrote:
I'd be wary of showing a desired value unless it's highly likely to
be accurate.
The desired value is accurately estimated based on (a) the total
number of exact/lossy pages
I wrote:
Robert Haas wrote:
I'd be wary of showing a desired value unless it's highly likely to
be accurate.
The desired value is accurately estimated based on (a) the total
number of exact/lossy pages stored in the TIDBitmap and (b) the
following equation in tbm_create(), except
I wrote:
Robert Haas wrote:
I'd be wary of showing a desired value unless it's highly likely to be
accurate.
The desired value is accurately estimated based on (a) the total number
of exact/lossy pages stored in the TIDBitmap and (b) the following
equation
in tbm_create(), except for the
Robert Haas wrote:
On Fri, Dec 6, 2013 at 5:02 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp
wrote:
Though at first I agreed on this, while working on this I start to
think information about (2) is enough for tuning work_mem. Here are
examples using a version under development, where
On Fri, Dec 6, 2013 at 5:02 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
Though at first I agreed on this, while working on this I start to think
information about (2) is enough for tuning work_mem. Here are examples using
a version under development, where Bitmap Memory Usage means
I wrote:
Amit Khandekar wrote:
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 agree with
Amit Khandekar wrote:
On 25 November 2013 13:37, Etsuro Fujita fujita.ets...@lab.ntt.co.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
From: Amit Khandekar [mailto:amit.khande...@enterprisedb.com]
On 1 November 2013 16:32, Etsuro Fujita fujita.ets...@lab.ntt.co.jp wrote:
From: Fujii Masao [mailto:masao.fu...@gmail.com]
I'm not sure if it's good idea to show the number of the fetches because it
seems difficult to tune
On 25 November 2013 13:37, Etsuro Fujita fujita.ets...@lab.ntt.co.jpwrote:
Reconsidering that, I wish to know your opinion. The patch shows the
number of exact/lossy pages that has been fetched in a bitmap heap scan.
But the number varies with the fraction of tuples to be retrieved like the
On 1 November 2013 16:32, Etsuro Fujita fujita.ets...@lab.ntt.co.jp wrote:
From: Fujii Masao [mailto:masao.fu...@gmail.com]
This is what I'm looking for! This feature is really useful for tuning
work_mem
when using full text search with pg_trgm.
I'm not sure if it's good idea to show
From: Fujii Masao [mailto:masao.fu...@gmail.com]
This is what I'm looking for! This feature is really useful for tuning
work_mem
when using full text search with pg_trgm.
I'm not sure if it's good idea to show the number of the fetches because it
seems difficult to tune work_mem from that
On Thu, Oct 31, 2013 at 7:54 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
Hi,
I think that lossy-heap-block information for a bitmap heap scan, not just
Rows
Removed by Index Recheck information, would also be a clue used to tune
work_mem for better performance especially when the
19 matches
Mail list logo
