On Thu, Mar 23, 2017 at 3:54 PM, Pavan Deolasee
<pavan.deola...@gmail.com> wrote:
> Thanks Amit. v19 addresses some of the comments below.
>
> On Thu, Mar 23, 2017 at 10:28 AM, Amit Kapila <amit.kapil...@gmail.com>
> wrote:
>>
>> On Wed, Mar 22, 2017 at 4:06 PM, Amit Kapila <amit.kapil...@gmail.com>
>> wrote:
>> > On Tue, Mar 21, 2017 at 6:47 PM, Pavan Deolasee
>> > <pavan.deola...@gmail.com> wrote:
>
>>
>> 5.
>> +btrecheck(Relation indexRel, IndexInfo *indexInfo, IndexTuple indexTuple,
>> + Relation heapRel, HeapTuple heapTuple)
>> {
>> ..
>> + if (!datumIsEqual(values[i - 1], indxvalue, att->attbyval,
>> + att->attlen))
>> ..
>> }
>>
>> Will this work if the index is using non-default collation?
>>
>
> Not sure I understand that. Can you please elaborate?
>I was worried for the case if the index is created non-default collation, will the datumIsEqual() suffice the need. Now again thinking about it, I think it will because in the index tuple we are storing the value as in heap tuple. However today it occurred to me how will this work for toasted index values (index value > TOAST_INDEX_TARGET). It is mentioned on top of datumIsEqual() that it probably won't work for toasted values. Have you considered that point? >> >> 6. >> +++ b/src/backend/access/nbtree/nbtxlog.c >> @@ -390,83 +390,9 @@ btree_xlog_vacuum(XLogReaderState *record) >> -#ifdef UNUSED >> xl_btree_vacuum *xlrec = (xl_btree_vacuum *) XLogRecGetData(record); >> >> /* >> - * This section of code is thought to be no longer needed, after analysis >> - * of the calling paths. It is retained to allow the code to be >> reinstated >> - * if a flaw is revealed in that thinking. >> - * >> .. >> >> Why does this patch need to remove the above code under #ifdef UNUSED >> > > Yeah, it isn't strictly necessary. But that dead code was coming in the way > and hence I decided to strip it out. I can put it back if it's an issue or > remove that as a separate commit first. > I think it is better to keep unrelated changes out of patch. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
