|From:||Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>|
|To:||Peter Geoghegan <pg(at)bowt(dot)ie>|
|Cc:||Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>|
|Subject:||Re: Parallel tuplesort (for parallel B-Tree index creation)|
|Views:||Raw Message | Whole Thread | Download mbox|
Attaching the re based patch according to the v22 parallel-hash patch sets
On Tue, Oct 10, 2017 at 2:53 PM, Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>
> On Sat, Sep 30, 2017 at 5:06 AM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>> On Wed, Sep 20, 2017 at 2:32 AM, Rushabh Lathia
>> <rushabh(dot)lathia(at)gmail(dot)com> wrote:
>> > Yes, I haven't touched the randomAccess part yet. My initial goal was
>> > to incorporate the BufFileSet api's here.
>> This is going to need a rebase, due to the commit today to remove
>> replacement selection sort. That much should be easy.
> Sorry for delay, here is rebase version of patch.
>> > Sorry, I didn't get this part. Are you talking about the your patch
>> > into OpenTemporaryFileInTablespace(), BufFileUnify() and other changes
>> > related to ltsUnify() ? If that's the case, I don't think it require
>> > the
>> > BufFileSet. Correct me if I am wrong here.
>> I thought that you'd have multiple BufFiles, which would be
>> multiplexed (much like a single BufFile itself mutiplexes 1GB
>> segments), so that logtape.c could still recycle space in the
>> randomAccess case. I guess that that's not a goal now.
> Hmm okay.
>> > To be frank its too early for me to comment anything in this area. I
>> > to study this more closely. As an initial goal I was just focused on
>> > understanding the current implementation of the patch and incorporate
>> > the BufFileSet APIs.
>> Fair enough.
> Rushabh Lathia
|Next Message||Rushabh Lathia||2017-10-26 11:24:20||Re: Parallel Hash take II|
|Previous Message||Amit Langote||2017-10-26 11:17:47||Re: path toward faster partition pruning|