Re: Don't try fetching future segment of a TLI. - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Don't try fetching future segment of a TLI.
Date
Msg-id 3e0713d2-56d2-9883-4213-d5ba7f0dcabf@oss.nttdata.com
Whole thread Raw
In response to Re: Don't try fetching future segment of a TLI.  (David Steele <david@pgmasters.net>)
Responses Re: Don't try fetching future segment of a TLI.
Re: Don't try fetching future segment of a TLI.
Re: Don't try fetching future segment of a TLI.
Re: Don't try fetching future segment of a TLI.
List pgsql-hackers

On 2020/04/07 4:04, David Steele wrote:
> On 4/6/20 1:43 PM, Fujii Masao wrote:
>>
>>
>> On 2020/03/19 22:22, Pavel Suderevsky wrote:
>>> Hi,
>>>
>>> I've tested patch provided by Kyotaro and do confirm it fixes the issue.
>>
>> The patch looks good to me. Attached is the updated version of the patch.
>> I updated only comments.
>>
>> Barring any objection, I will commit this patch.
> 
> The patch looks good to me.
> 
>>> Any chance it will be merged to one of the next minor releases?
>>
>> This doesn't seem a bug, so I'm thinking to merge this to next *major*
>> version release, i.e., v13.
> 
> Not a bug, perhaps, but I think we do consider back-patching performance problems. The rise in S3 usage has just
exposedhow poorly this performed code in high-latency environments.
 

I understood the situation and am fine to back-patch that. But I'm not sure
if it's fair to do that. Maybe we need to hear more opinions about this?
OTOH, feature freeze for v13 is today, so what about committing the patch
in v13 at first, and then doing the back-patch after hearing opinions and
receiving many +1?

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: [PATCH] Incremental sort (was: PoC: Partial sort)
Next
From: Amit Langote
Date:
Subject: Re: d25ea01275 and partitionwise join