On Fri, Jan 15, 2016 at 2:38 PM, Constantin S. Pan <kva...@gmail.com> wrote: > I have a draft implementation which divides the whole process between > N parallel workers, see the patch attached. Instead of a full scan of > the relation, I give each worker a range of blocks to read.
I am currently working on a patch that allows B-Tree index builds to be performed in parallel. I think I'm a week or two away from posting it. Even without parallelism, wouldn't it be better if GIN indexes were built using tuplesort? I know way way less about the gin am than the nbtree am, but I imagine that a prominent cost for GIN index builds is constructing the main B-Tree (the one that's constructed over key values) itself. Couldn't tuplesort.c be adapted to cover this case? That would be much faster in general, particularly with the recent addition of abbreviated keys, while also leaving a clear path forward to performing the build in parallel. I understand that a long term ambition for the gin am is to merge it with nbtree, to almost automatically benefit from enhancements, and to reduce the maintenance burden of each. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers