Hi,
On 2018-01-04 11:39:40 -0500, Robert Haas wrote:
> On Tue, Jan 2, 2018 at 1:09 AM, Mithun Cy <mithun.cy@enterprisedb.com> wrote:
> > So in case of N_RELEXTLOCK_ENTS = 1 we can see regression as high 25%. ?
>
> So now the question is: what do these results mean for this patch?
> I think that the chances of someone simultaneously bulk-loading 16 or
> more relations that all happen to hash to the same relation extension
> lock bucket is pretty darn small.
I'm not convinced that that's true. Especially with partitioning in the
mix.
Also, birthday paradoxon and all that make collisions not that
unlikely. And you really don't need a 16 way conflict to feel pain,
you'll imo feel it earlier.
I think bumping up the size a bit would make that less likely. Not sure
it actually addresses the issue.
> However, if we take the position that no hash collision probability is
> low enough and that we must eliminate all chance of false collisions,
> except perhaps when the table is full, then we have to make this
> locking mechanism a whole lot more complicated. We can no longer
> compute the location of the lock we need without first taking some
> other kind of lock that protects the mapping from {db_oid, rel_oid} ->
> {memory address of the relevant lock}.
Hm, that's not necessarily true, is it? Wile not trivial, it also
doesn't seem impossible?
Greetings,
Andres Freund