From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Resource Owner reassign Locks |
Date: | 2012-06-15 22:29:16 |
Message-ID: | 5206.1339799356@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> On Mon, Jun 11, 2012 at 9:30 PM, Amit Kapila <amit(dot)kapila(at)huawei(dot)com> wrote:
>> MAX_RESOWNER_LOCKS - How did you arrive at number 10 for it. Is there any
>> specific reason for 10.
> I instrumented the code to record the maximum number of locks held by
> a resource owner, and report the max when it was destroyed. (That
> code is not in this patch). During a large pg_dump, the vast majority
> of the resource owners had maximum locks of 2, with some more at 4
> and 6. Then there was one resource owner, for the top-level
> transaction, at tens or hundreds of thousands (basically one for every
> lockable object). There was little between 6 and this top-level
> number, so I thought 10 was a good compromise, safely above 6 but not
> so large that searching through the list itself was likely to bog
> down.
> Also, Tom independently suggested the same number.
FYI, I had likewise suggested 10 on the basis of examining pg_dump's
behavior. It might be a good idea to examine a few other use-cases
before settling on a value.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2012-06-15 22:30:27 | Re: Event Triggers reduced, v1 |
Previous Message | Tom Lane | 2012-06-15 22:25:20 | Re: libpq compression |