On Wed, Mar 28, 2018 at 10:30 AM, Tom Lane wrote:
> It looks good to me. The only real objection would be if someone came
> up with a test case proving that there's a significant performance
> degradation from the extra copies. But given that these are back
> branches, it would take a pretty ste
Peter Geoghegan writes:
> On Mon, Mar 26, 2018 at 5:14 AM, Kyotaro HORIGUCHI
> wrote:
>> If no one objects, I'll mark this as Ready for Commit in a couple
>> of days.
> Thank you for the review, Horiguchi-san. It's hard to decide how
> important each goal is when coming up with a back-patchable
On Tue, Mar 27, 2018 at 2:23 AM, Kyotaro HORIGUCHI
wrote:
>> > If no one objects, I'll mark this as Ready for Commit in a couple
>> > of days.
>>
>> Thank you for the review, Horiguchi-san. It's hard to decide how
>> important each goal is when coming up with a back-patchable fix like
>> this. Whe
At Mon, 26 Mar 2018 20:40:51 -0700, Peter Geoghegan wrote in
> On Mon, Mar 26, 2018 at 5:14 AM, Kyotaro HORIGUCHI
> wrote:
> >> Attached patches do it that way. I'm happy with what I came up with,
> >> which is a lot simpler than my first approach. The extra copying seems
> >> likely to be well
On Mon, Mar 26, 2018 at 5:14 AM, Kyotaro HORIGUCHI
wrote:
>> Attached patches do it that way. I'm happy with what I came up with,
>> which is a lot simpler than my first approach. The extra copying seems
>> likely to be well worth it, since it is fairly isolated in practice,
>> especially on 9.6.
At Thu, 22 Feb 2018 16:22:47 -0800, Peter Geoghegan wrote in
> On Mon, Feb 12, 2018 at 6:15 PM, Peter Geoghegan wrote:
> > * For 9.5 and 9.6, the approach taken in bugfix commit d8589946d
> > should be taken even further -- we should always copy. Moreover, we
> > should always copy within tuple
On Mon, Feb 12, 2018 at 6:15 PM, Peter Geoghegan wrote:
> * For 9.5 and 9.6, the approach taken in bugfix commit d8589946d
> should be taken even further -- we should always copy. Moreover, we
> should always copy within tuplesort_getdatum(), for the same reasons.
>
> * For 9.5, 9.6, 10, and maste
On Wed, Feb 7, 2018 at 7:02 PM, Peter Geoghegan wrote:
> On Wed, Feb 7, 2018 at 4:41 PM, Tom Lane wrote:
>> Peter Geoghegan writes:
>>> It would be nice to get an opinion on this mode_final() + tuplesort
>>> memory lifetime business from you, Tom.
>>
>> I'm fairly sure that that bit in mode_fina
On Wed, Feb 7, 2018 at 4:41 PM, Tom Lane wrote:
> Peter Geoghegan writes:
>> It would be nice to get an opinion on this mode_final() + tuplesort
>> memory lifetime business from you, Tom.
>
> I'm fairly sure that that bit in mode_final() was just a hack to make
> it work. If there's a better, mo
Peter Geoghegan writes:
> On Wed, Jan 17, 2018 at 2:23 PM, Peter Geoghegan wrote:
>> A complicating factor for this fix of mine is that mode_final() seems
>> to have its own ideas about tuple memory lifetime, over and above what
>> tuplesort_getdatum() explicitly promises, as can be seen here:
>>
On Tue, Feb 6, 2018 at 5:54 PM, Craig Ringer wrote:
>> In a quick look at the patches, WIP-kludge-fix.patch seems clearly
>> unacceptable for back-patching because it changes the signature and
>> behavior of ExecResetTupleTable, which external code might well be using.
> Definitely is using, in t
On 18 January 2018 at 03:23, Tom Lane wrote:
> Aleksandr Parfenov writes:
> > The new status of this patch is: Ready for Committer
>
> I don't feel particularly comfortable committing a patch that
> was clearly labeled as a rushed draft by its author.
> Peter, where do you stand on this work?
>
On Wed, Jan 17, 2018 at 2:23 PM, Peter Geoghegan wrote:
> A complicating factor for this fix of mine is that mode_final() seems
> to have its own ideas about tuple memory lifetime, over and above what
> tuplesort_getdatum() explicitly promises, as can be seen here:
>
> /*
> * Note: we *cannot* cl
On Wed, Jan 17, 2018 at 1:00 PM, Tom Lane wrote:
>> You could make the same objection to changing tuplesort_getdatum()
>> outside of the master branch, though. I think that going back further
>> than that for the (arguably independent) tuplesort_getdatum() subset
>> fix might still be a good idea.
Peter Geoghegan writes:
> On Wed, Jan 17, 2018 at 12:31 PM, Tom Lane wrote:
>> +1. If the problem isn't known to be reproducible in those branches,
>> the risk of adding new bugs seems to outweigh any benefit.
> You could make the same objection to changing tuplesort_getdatum()
> outside of the
On Wed, Jan 17, 2018 at 12:31 PM, Tom Lane wrote:
> Probably not very. It'd be nice to have it done by the next minor
> releases, ie before 5-Feb ... but given that these bugs are years
> old, missing that deadline would not be catastrophic.
Got it.
>> I'm not sure whether or not we should also
Peter Geoghegan writes:
> On Wed, Jan 17, 2018 at 11:23 AM, Tom Lane wrote:
>> I don't feel particularly comfortable committing a patch that
>> was clearly labeled as a rushed draft by its author.
>> Peter, where do you stand on this work?
> I would like to take another pass over
> WIP-tuplesort
On Wed, Jan 17, 2018 at 11:23 AM, Tom Lane wrote:
> Aleksandr Parfenov writes:
>> The new status of this patch is: Ready for Committer
>
> I don't feel particularly comfortable committing a patch that
> was clearly labeled as a rushed draft by its author.
> Peter, where do you stand on this work?
Aleksandr Parfenov writes:
> The new status of this patch is: Ready for Committer
I don't feel particularly comfortable committing a patch that
was clearly labeled as a rushed draft by its author.
Peter, where do you stand on this work?
In a quick look at the patches, WIP-kludge-fix.patch seems
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Hi,
All information is related to WIP-tuplesort-memcontext-f
20 matches
Mail list logo
