Re: Reduce pinning in btree indexes - Mailing list pgsql-hackers

Just a reminder, but I am not the author of this patch:)

At Fri, 27 Feb 2015 07:26:38 +0000, Andrew Gierth <andrew@tao11.riddles.org.uk> wrote in
<87zj7z6ckc.fsf@news-spur.riddles.org.uk>
> >>>>> "Kyotaro" == Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes:
> 
>  >> You might want to try running the same test, but after patching
>  >> ExecSupportsMarkRestore to return false for index scans. This will
>  >> cause the planner to insert a Materialize node to handle the
>  >> mark/restore.
> 
>  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.

I understand that you'd like to see the net drag of performance
by the memcpy(), right?

That don't seem to be possible without breaking (a part of) the
patch's function, but, concerning btmarkpos() only case, the mark
struct can have garbage so only changing refcount would be viable
to see the pure loss by the memcpy().

The attached patch is the destruction I did, and the result was
like below.

> Case 2. 1M markpos, no restorepos for 1M result rows.
> 
> IndesOnly scan: The patches loses about 10%.
>   master:  3655 ms (std dev = 2.5 ms)
>   Patched: 4038 ms (std dev = 2.6 ms)
  Patched: 4036 ms (std dev = 3.5 ms)  Broken:  3718 ms (std dev = 1.6 ms)

The "Patched" just above is the retook numbers. It's a little
under 9% loss from "broken" version. That is the pure drag of
memcpy(). This seems quite big as Heikki said. It's an extreme
case, though.

The rest 1.7% should be the share of all the other stuff.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/backend/access/nbtree/nbtree.c b/src/backend/access/nbtree/nbtree.c
index 65daf27..4973b63 100644
--- a/src/backend/access/nbtree/nbtree.c
+++ b/src/backend/access/nbtree/nbtree.c
@@ -547,12 +547,17 @@ btmarkpos(PG_FUNCTION_ARGS)    BTScanOpaque so = (BTScanOpaque) scan->opaque;
hoge_markpos_count++;
-    memcpy(&so->markPos, &so->currPos,
-           offsetof(BTScanPosData, items[1]) +
-           so->currPos.lastItem * sizeof(BTScanPosItem));
-    if (so->markTuples)
-        memcpy(so->markTuples, so->currTuples,
-               so->currPos.nextTupleOffset);
+//    memcpy(&so->markPos, &so->currPos,
+//           offsetof(BTScanPosData, items[1]) +
+//           so->currPos.lastItem * sizeof(BTScanPosItem));
+//    if (so->markTuples)
+//        memcpy(so->markTuples, so->currTuples,
+//               so->currPos.nextTupleOffset);
+    if (BTScanPosIsValid(so->markPos))
+    {
+        ReleaseBuffer(so->markPos.buf);
+        so->markPos.buf = InvalidBuffer;
+    }    /* We don't take out an extra pin for the mark position. */    so->markPos.buf = InvalidBuffer;
@@ -599,12 +604,13 @@ btrestrpos(PG_FUNCTION_ARGS)        if (BTScanPosIsValid(so->markPos))        {
-            memcpy(&so->currPos, &so->markPos,
-                   offsetof(BTScanPosData, items[1]) +
-                   so->markPos.lastItem * sizeof(BTScanPosItem));
-            if (so->currTuples)
-                memcpy(so->currTuples, so->markTuples,
-                       so->markPos.nextTupleOffset);
+//            memcpy(&so->currPos, &so->markPos,
+//                   offsetof(BTScanPosData, items[1]) +
+//                   so->markPos.lastItem * sizeof(BTScanPosItem));
+//            if (so->currTuples)
+//                memcpy(so->currTuples, so->markTuples,
+//                       so->markPos.nextTupleOffset);
+            IncrBufferRefCount(so->markPos.buf);                    }        else
BTScanPosInvalidate(so->currPos);