Hello. Mmm... We might be focusing on a bit different things..
2015/02/27 17:27 "Andrew Gierth" > 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_. The mark/restore works as before with this patch, except the stuff for early dropping of buffer pins. As far as my understanding so far all the stuff in the patch is for the purpose but doesn't intend to boost btree itself. That is, it reduces the chance to block vacuum for possible burden on general performance. And I think the current issue in focus is that the burden might a bit too heavy on specific situation. Therefore I tried to measure how heavy/light the burden is. Am I correct so far? > 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? As you mentioned before, such change will make the planner turn to, perhaps materialize plan or rescan, or any other scans which are no use comparing to indexscan concerning the issue in focus, the performance drag when btree scan does extremely frequent mark/restore in comparison to unpatched, less copy-amount version. Your suggestion looks intending somewhat different from this. Anyway I'm sorry but I have left my dev env and cannot have time till next week. regards, -- Kyotaro Horiguti