Re: Reduce pinning in btree indexes

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