Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()
Дата
Msg-id CAH2-WznenBgh34ng3bqDGu8CXZid_eh1G8s9oBcWMwVC8098MQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()  (Thomas Munro <thomas.munro@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: Internal key management system
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: PL/Python - lifetime of variables?