Re: Reduce pinning in btree indexes
От | Andrew Gierth |
---|---|
Тема | Re: Reduce pinning in btree indexes |
Дата | |
Msg-id | 87vbin69ym.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | Re: Reduce pinning in btree indexes (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: Reduce pinning in btree indexes
|
Список | pgsql-hackers |
>>>>> "Kyotaro" == Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.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 changeKyotaro> for ExecSupportMarkRestore and the very simplefunction remainKyotaro> looking to return true for T_Index(Only)Scan after the patchKyotaro> applied. >> Right. I'm suggesting you change that, in order to determine what>> performance cost, if any, would result from abandoningthe idea of>> doing mark/restore entirely. Kyotaro> I understand that you'd like to see the net drag ofKyotaro> 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)
В списке pgsql-hackers по дате отправления: