Re: Reduce pinning in btree indexes

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: kgrittn(at)ymail(dot)com, hlinnakangas(at)vmware(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Reduce pinning in btree indexes
Date: 2015-02-27 08:27:37
Message-ID: 87vbin69ym.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>>>> "Kyotaro" == Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)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)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2015-02-27 08:52:34 Re: Re: [pgadmin-support] Issue with a hanging apply process on the replica db after vacuum works on primary
Previous Message Kyotaro HORIGUCHI 2015-02-27 08:14:24 Re: Reduce pinning in btree indexes