Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare() - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()
Date
Msg-id CAH2-WznenBgh34ng3bqDGu8CXZid_eh1G8s9oBcWMwVC8098MQ@mail.gmail.com
Whole thread Raw
In response to Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
On Tue, Feb 18, 2020 at 4:45 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> Yeah, for CF entries with multiple threads, it currently looks at
> whichever thread has the most recent email on it, and then it finds
> the most recent patch set on that thread.  Perhaps it should look at
> all the registered threads and find the message with the newest patch
> set across all of them, as you say.  I will look into that.

Thanks!

I know that I am a bit unusual in that I use all of the CF app
features at the same time. But the current behavior of CF Tester
disincentivizes using multiple threads. This works against the goal of
having good metadata about patches that are worked on over multiple
releases or years. We have a fair few of those.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Internal key management system
Next
From: Craig Ringer
Date:
Subject: Re: PL/Python - lifetime of variables?