From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com> |
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) |
Date: | 2017-09-29 23:36:55 |
Message-ID: | CAH2-WzmRfZWpGEpuiURqmkSp6psCJULcoo9xQcrna994Dc3AWQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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, I didn't get this part. Are you talking about the your patch changes
> into OpenTemporaryFileInTablespace(), BufFileUnify() and other changes
> related to ltsUnify() ? If that's the case, I don't think it require with
> 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.
> To be frank its too early for me to comment anything in this area. I need
> 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.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2017-09-29 23:38:00 | Re: CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it? |
Previous Message | Nikita Glukhov | 2017-09-29 23:06:29 | Re: SQL/JSON in PostgreSQL |