On Fri, Aug 19, 2016 at 4:44 PM, Amit Kapila
wrote:
>Can you specify the m/c details as Andres wants tests to be conducted on
some high socket m/c?
As I have specified at the last line of my mail it is a 8 socket intel
machine.
available: 8 nodes (0-7)
node 0 cpus: 0 65 66 67 68 69 70 71 96 97 9
On Fri, Aug 19, 2016 at 4:29 PM, Mithun Cy
wrote:
> On Wed, Aug 17, 2016 at 9:12 PM, Andres Freund wrote:
>
>> >Yes. I want a long wait list, modified in bulk - which should be the
>> >case with the above.
>>
>
> I ran some pgbench. And, I do not see much difference in performance,
> small varia
On Wed, Aug 17, 2016 at 9:12 PM, Andres Freund wrote:
> >Yes. I want a long wait list, modified in bulk - which should be the
> >case with the above.
>
I ran some pgbench. And, I do not see much difference in performance, small
variance in perf can be attributed to variance in probability of dra
On 2016-08-17 08:31:36 -0400, Robert Haas wrote:
> On Tue, Aug 16, 2016 at 5:03 PM, Andres Freund wrote:
> > On 2016-08-15 18:15:23 -0400, Robert Haas wrote:
> >> On Thu, Aug 11, 2016 at 2:19 PM, Robert Haas wrote:
> >> > Therefore, I plan to commit this patch, removing the #include
> >> > unles
On 2016-08-16 23:09:07 -0400, Robert Haas wrote:
> On Tue, Aug 16, 2016 at 5:03 PM, Andres Freund wrote:
> > On 2016-08-15 18:15:23 -0400, Robert Haas wrote:
> >> On Thu, Aug 11, 2016 at 2:19 PM, Robert Haas wrote:
> >> > Therefore, I plan to commit this patch, removing the #include
> >> > unles
On Tue, Aug 16, 2016 at 5:03 PM, Andres Freund wrote:
> On 2016-08-15 18:15:23 -0400, Robert Haas wrote:
>> On Thu, Aug 11, 2016 at 2:19 PM, Robert Haas wrote:
>> > Therefore, I plan to commit this patch, removing the #include
>> > unless someone convinces me we need it, shortly after
>> > devel
On Tue, Aug 16, 2016 at 5:03 PM, Andres Freund wrote:
> On 2016-08-15 18:15:23 -0400, Robert Haas wrote:
>> On Thu, Aug 11, 2016 at 2:19 PM, Robert Haas wrote:
>> > Therefore, I plan to commit this patch, removing the #include
>> > unless someone convinces me we need it, shortly after
>> > devel
On 2016-08-15 18:15:23 -0400, Robert Haas wrote:
> On Thu, Aug 11, 2016 at 2:19 PM, Robert Haas wrote:
> > Therefore, I plan to commit this patch, removing the #include
> > unless someone convinces me we need it, shortly after
> > development for v10 opens, unless there are objections before then
On Thu, Aug 11, 2016 at 2:19 PM, Robert Haas wrote:
> Therefore, I plan to commit this patch, removing the #include
> unless someone convinces me we need it, shortly after
> development for v10 opens, unless there are objections before then.
Hearing no objections, done.
--
Robert Haas
Enterpri
On Thu, Jul 28, 2016 at 6:51 PM, Thomas Munro
wrote:
> That version didn't actually make LWLock any smaller, because of the
> additional offset stored in proclist_head when initialising the list.
> Here is a new version that requires callers to provide it when
> accessing the list, bringing sizeof
On Fri, Jul 29, 2016 at 2:12 AM, Robert Haas wrote:
> On Thu, Jul 28, 2016 at 12:12 AM, Thomas Munro
> wrote:
>> On Tue, Jul 26, 2016 at 6:00 AM, Andres Freund wrote:
>>> I think the better fix here would acutally be to get rid of a pointer
>>> based list here, and a) replace the queue with inte
On Thu, Jul 28, 2016 at 12:12 AM, Thomas Munro
wrote:
> On Tue, Jul 26, 2016 at 6:00 AM, Andres Freund wrote:
>> I think the better fix here would acutally be to get rid of a pointer
>> based list here, and a) replace the queue with integer offsets ...
>
> Here is a prototype of that idea. It re
On Tue, Jul 26, 2016 at 6:00 AM, Andres Freund wrote:
> I think the better fix here would acutally be to get rid of a pointer
> based list here, and a) replace the queue with integer offsets ...
Here is a prototype of that idea. It replaces that dlist with a
proclist, a new specialised doubly-li
Hi,
On 2016-07-25 15:02:41 +1200, Thomas Munro wrote:
> > Any thoughts on this approach, or better ways to solve this problem?
> > How valuable is the branch-free property of the circular push and
> > delete operations?
I think it's generally valuable, but I suspect that it doesn't really
matter
On Sun, Jul 24, 2016 at 11:02 PM, Thomas Munro
wrote:
> On Sun, Jul 24, 2016 at 1:10 AM, Thomas Munro
> wrote:
>> One solution could be to provide a non-circular variant of the dlist
>> interface that uses NULL list termination. I've attached a quick
>> sketch of something like that which seems
On Mon, Jul 25, 2016 at 3:02 PM, Thomas Munro
wrote:
> I measured the following times for unpatched master, on my 4 core laptop:
>
> 16 workers = 73.067s, 74.869s, 75.338s
> 8 workers = 65.846s, 67.622s, 68.039s
> 4 workers = 68.763s, 68.980s, 69.035s <-- curiously slower here
> 3 workers = 59.
On Sun, Jul 24, 2016 at 1:10 AM, Thomas Munro
wrote:
> One solution could be to provide a non-circular variant of the dlist
> interface that uses NULL list termination. I've attached a quick
> sketch of something like that which seems to work correctly. It is
> only lightly tested so far and pro
Hi,
As already noted[1], LWLocks don't currently work in DSM segments,
because they use dlist for the list of waiters. Even though all of
the waiter nodes are in PGPROC and therefore have stable addresses,
the dlist code internally constructs a circular list including
pointers to a special sentin
18 matches
Mail list logo
