On Saturday, September 5, 2015, Tatsuo Ishii wrote:
> > Tatsuo Ishii wrote:
> >> > On 9/4/2015 2:04 PM, Tatsuo Ishii wrote:
> >> >>> One thing I imagine we could do is to change the signature of
> >> >>> summrize_range() to also include heapNumBlks which its (only) caller
> >> >>> brinsummarize()
> Tatsuo Ishii wrote:
>> > On 9/4/2015 2:04 PM, Tatsuo Ishii wrote:
>> >>> One thing I imagine we could do is to change the signature of
>> >>> summrize_range() to also include heapNumBlks which its (only) caller
>> >>> brinsummarize() already computes. It will look like:
>> >>>
>> >>> static void
Tatsuo Ishii wrote:
> > On 9/4/2015 2:04 PM, Tatsuo Ishii wrote:
> >>> One thing I imagine we could do is to change the signature of
> >>> summrize_range() to also include heapNumBlks which its (only) caller
> >>> brinsummarize() already computes. It will look like:
> >>>
> >>> static void summariz
> On Fri, Sep 4, 2015 at 10:03 AM, Tatsuo Ishii wrote:
>>
>> I have looked into your patch and am a little bit worried because it
>> calls RelationGetNumberOfBlocks() which is an expensive function.
>> I think there are two ways to avoid it.
>>
>> 1) fall back to your former patch. However it may
On Fri, Sep 4, 2015 at 10:03 AM, Tatsuo Ishii wrote:
>
> I have looked into your patch and am a little bit worried because it
> calls RelationGetNumberOfBlocks() which is an expensive function.
> I think there are two ways to avoid it.
>
> 1) fall back to your former patch. However it may break ex
> On 9/4/2015 2:04 PM, Tatsuo Ishii wrote:
>>> One thing I imagine we could do is to change the signature of
>>> summrize_range() to also include heapNumBlks which its (only) caller
>>> brinsummarize() already computes. It will look like:
>>>
>>> static void summarize_range(IndexInfo *indexInfo, Br
On 9/4/2015 2:04 PM, Tatsuo Ishii wrote:
>> One thing I imagine we could do is to change the signature of
>> summrize_range() to also include heapNumBlks which its (only) caller
>> brinsummarize() already computes. It will look like:
>>
>> static void summarize_range(IndexInfo *indexInfo, BrinBuild
> One thing I imagine we could do is to change the signature of
> summrize_range() to also include heapNumBlks which its (only) caller
> brinsummarize() already computes. It will look like:
>
> static void summarize_range(IndexInfo *indexInfo, BrinBuildState *state,
>
On 9/4/2015 1:33 PM, Tatsuo Ishii wrote:
>> Ah, it did cross my mind to the fix it in brin.c but was not sure. I did
>> it that way in the attached patch.
>
> Amit,
>
> I have looked into your patch and am a little bit worried because it
> calls RelationGetNumberOfBlocks() which is an expensive f
> On 9/4/2015 8:28 AM, Tatsuo Ishii wrote:
>>>
>>> Attached hack fixes the symptom but perhaps not the correct fix for this.
>>
>> Why can't we fix summarize_range() in brin.c:
>>
>> IndexBuildHeapRangeScan(heapRel, state->bs_irel, indexInfo, false, true,
>>
On 9/4/2015 12:01 PM, Alvaro Herrera wrote:
> Amit Langote wrote:
>> On 9/4/2015 9:22 AM, Tatsuo Ishii wrote:
>>>
>>> 3) I wonder if other index type is suffered by this type of bug.
>>>
>>
>> About 3, it seems unlikely. Both the IndexBuildHeapRangeScan() and
>> heap_setscanlimits() were introduced
Amit Langote wrote:
> On 9/4/2015 9:22 AM, Tatsuo Ishii wrote:
> >>
> >> In this case, scan->rs_startblock is 384 set by IndexBuildHeapRangeScan()
> >> using heap_setscanlimits(). One can imagine how the above heap finish
> >> criteria might not work as expected.
> >
> > What scares me is:
> >
>
On 9/4/2015 8:28 AM, Tatsuo Ishii wrote:
>>
>> Attached hack fixes the symptom but perhaps not the correct fix for this.
>
> Why can't we fix summarize_range() in brin.c:
>
> IndexBuildHeapRangeScan(heapRel, state->bs_irel, indexInfo, false, true,
>
On 9/4/2015 9:22 AM, Tatsuo Ishii wrote:
>>
>> In this case, scan->rs_startblock is 384 set by IndexBuildHeapRangeScan()
>> using heap_setscanlimits(). One can imagine how the above heap finish
>> criteria might not work as expected.
>
> What scares me is:
>
> 1) the bug will not be found unless
> The summarization during VACUUM invokes IndexBuildHeapRangeScan() which is
> passed scanStartBlock and scanNumBlocks. If scanStartBlock + scanNumBlocks
>> heapTotalBlocks, further down the line, heapgettup() may start returning
> tuples from the beginning given the following code in it:
>
> pa
> The summarization during VACUUM invokes IndexBuildHeapRangeScan() which is
> passed scanStartBlock and scanNumBlocks. If scanStartBlock + scanNumBlocks
>> heapTotalBlocks, further down the line, heapgettup() may start returning
> tuples from the beginning given the following code in it:
>
> pa
On 9/3/2015 5:49 PM, Tatsuo Ishii wrote:
>
> However I inserted data *after* creating index, the value is
> different.
> VACUUM;
> VACUUM
> SELECT * FROM brin_revmap_data(get_raw_page('brinidx', 1)) WHERE pages !=
> '(0,0)'::tid;
> pages
> ---
> (2,1)
> (2,2)
> (2,3)
> (2,4)
> (4 rows)
When creating a brin index, it shows an interesting behavior when used
with VACUUM.
First, I created a brin index after inserting data.
===
DROP TABLE t1;
DROP TABLE
CREATE TABLE t1(i int);
CREATE TABLE
INSERT INTO t1 VALUES (generate_ser
18 matches
Mail list logo
