Re: Relation extension scalability - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Relation extension scalability
Date
Msg-id CAA4eK1JWu5Xhmnpe2hOXw7WbHtBW6BacoiOMR106i2+Zv4xf8A@mail.gmail.com
Whole thread Raw
In response to Re: Relation extension scalability  (Petr Jelinek <petr@2ndquadrant.com>)
Responses Re: Relation extension scalability
List pgsql-hackers
On Tue, Mar 29, 2016 at 3:21 AM, Petr Jelinek <petr@2ndquadrant.com> wrote:
On 28/03/16 14:46, Dilip Kumar wrote:

    Conclusion:
    ---------------
    1. I think v15 is solving the problem exist with v13 and performance
    is significantly high compared to base, and relation size is also
    stable, So IMHO V15 is winner over other solution, what other thinks ?


It seems so, do you have ability to reasonably test with 64 clients? I am mostly wondering if we see the performance going further down or just plateau.


Yes, that makes sense.  One more point is that if the reason for v13 giving better performance is extra blocks (which we believe in certain cases can leak till the time Vacuum updates the FSM tree), do you think it makes sense to once test by increasing lockWaiters * 20 limit to may be lockWaiters * 25 or lockWaiters * 30.


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

pgsql-hackers by date:

Previous
From: Christian Ullrich
Date:
Subject: Re: [COMMITTERS] pgsql: Sync tzload() and tzparse() APIs with IANA release tzcode2016c.
Next
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: pgbench: Support double constants and functions.