Re: Partitioned tables and covering indexes - Mailing list pgsql-hackers

From Teodor Sigaev
Subject Re: Partitioned tables and covering indexes
Date
Msg-id 5ee72852-3c4e-ee35-e2ed-c1d053d45c08@sigaev.ru
Whole thread Raw
In response to Re: Partitioned tables and covering indexes  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: Partitioned tables and covering indexes
List pgsql-hackers
Patch makes buildfarm almost red, patch is temporary reverted.

Actually, discovered bug is not related to patch except new test faces with it,
problem is: CompareIndexInfo() checks rd_opfamily for equality for all 
attributes, not only for key attribute.

Obviously, CompareIndexInfo() needs more work:
     for (i = 0; i < info1->ii_NumIndexAttrs; i++)
     {
         if (maplen < info2->ii_KeyAttrNumbers[i])

Seems, we can go out from ii_KeyAttrNumbers array.




Amit Langote wrote:
> Hi.
> 
> On 2018/04/11 0:36, Teodor Sigaev wrote:
>>>      Does the attached fix look correct?  Haven't checked the fix with
>>> ATTACH
>>>      PARTITION though.
>>>
>>>
>>> Attached patch seems to fix the problem.  However, I would rather get
>>> rid of modifying stmt->indexParams.  That seems to be more logical
>>> for me.  Also, it would be good to check some covering indexes on
>>> partitioned tables.  See the attached patch.
>>
>> Seems right way, do not modify incoming object and do not copy rather
>> large and deep nested structure as suggested by Amit.
> 
> Yeah, Alexander's suggested way of using a separate variable for
> indexParams is better.
> 
>> But it will  be better to have a ATTACH PARTITION test too.
> 
> I have added tests.  Actually, instead of modifying existing tests, I
> think it might be better to have a separate section at the end of
> indexing.sql to test covering indexes feature for partitioned tables.
> 
> Attached find updated patch.
> 
> Thanks,
> Amit
> 

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
                                                    WWW: http://www.sigaev.ru/


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 'make check' fails
Next
From: Alvaro Herrera
Date:
Subject: Re: 'make check' fails