Re: group locking: incomplete patch, just for discussion

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: group locking: incomplete patch, just for discussion
Date: 2014-10-29 12:08:38
Message-ID: CAA4eK1+kwGSLeA2188zM2_QE4yJssTx8nd9OGa7ypJjYeuQo0w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 29, 2014 at 2:18 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
> My proposal is we do a parallel index build scan... just as we
> discussed earlier, so you would be following the direction set by Dev
> Meeting, not just a proposal of mine.
>
> As I mentioned previously when you started discussing shared memory
> segments, parallel sort does NOT require shared memory. The only thing
> you need to share are files. Split the problem into N pieces, sort
> them to produce N files and then merge the files using existing code.
> That only applies to large sorts, but then those are the ones you
> cared about doing in parallel anyway.
>
> CREATE INDEX has a lock on the table. Worker tasks can be simply
> banned from acquiring new locks and doing many other tasks.

Banning worker tasks from taking locks is only possible if the
worker backend doesn't need to acquire any lock which is not
already acquired by main backend, but can we safely assume
the same? One example as taken by Robert upthread about
bttextcmp() can break that assumption.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2014-10-29 12:16:35 Re: WITH CHECK and Column-Level Privileges
Previous Message Stephen Frost 2014-10-29 11:58:08 Re: Allow peer/ident to fall back to md5?