>>>>> "Kyotaro" == Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> writes:
Kyotaro> Just a reminder, but I am not the author of this patch:) Yes, I understand that. Kyotaro> Mmm? The patch bt-nopin-v1.patch seems not contain the change Kyotaro> for ExecSupportMarkRestore and the very simple function remain Kyotaro> looking to return true for T_Index(Only)Scan after the patch Kyotaro> applied. >> Right. I'm suggesting you change that, in order to determine what >> performance cost, if any, would result from abandoning the idea of >> doing mark/restore entirely. Kyotaro> I understand that you'd like to see the net drag of Kyotaro> performance by the memcpy(), right? No. What I am suggesting is this: if mark/restore is a performance issue, then it would be useful to know how much gain we're getting (if any) from supporting it _at all_. Let me try and explain it another way. If you change ExecSupportMarkRestore to return false for index scans, then btmarkpos/btrestorepos will no longer be called. What is the performance of this case compared to the original and patched versions? -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
