<div dir="ltr"><p dir="ltr">Hello.<p dir="ltr">Mmm... We might be focusing on a bit different things..<p
dir="ltr">2015/02/2717:27 "Andrew Gierth" > Kyotaro> I understand that you'd like to see the net drag of<br />
> Kyotaro> performance by the memcpy(), right?<br /> ><br /> > No.<br /> ><br /> > What I am
suggestingis this: if mark/restore is a performance issue,<br /> > then it would be useful to know how much gain
we'regetting (if any)<br /> > from supporting it _at all_.<p dir="ltr">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
isfor 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
heavyon specific situation. Therefore I tried to measure how heavy/light the burden is.<p dir="ltr">Am I correct so
far?<pdir="ltr">> Let me try and explain it another way. If you change<br /> > ExecSupportMarkRestore to return
falsefor index scans, then<br /> > btmarkpos/btrestorepos will no longer be called. What is the performance<br />
>of this case compared to the original and patched versions?<p dir="ltr">As you mentioned before, such change will
makethe planner turn to, perhaps materialize plan or rescan, or any other scans which are no use comparing to indexscan
concerningthe 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.<p
dir="ltr">AnywayI'm sorry but I have left my dev env and cannot have time till next week.<p>regards,<br /><p
dir="ltr">--<br /> Kyotaro Horiguti<br /></div>
