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

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Floris Van Nee <florisvannee(at)optiver(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()
Date: 2020-02-19 01:37:40
Message-ID: CAH2-WznenBgh34ng3bqDGu8CXZid_eh1G8s9oBcWMwVC8098MQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 18, 2020 at 4:45 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2020-02-19 01:39:16 Re: PL/Python - lifetime of variables?
Previous Message Craig Ringer 2020-02-19 01:35:41 Re: Internal key management system