On 07/26/2011 12:33 PM, Pavan Deolasee wrote:
I think what I am suggesting is that the default pgbench test setup
would probably not give you a good scalability as number of clients
are increased and one reason could be the contention in the small
table. So it might be a good idea to get rid of t
On Tue, Jul 26, 2011 at 4:40M, Pavan Deolasee wrote:
> On Tue, Jul 26, 2011 at 9:07 AM, Robert Haas wrote:
>> On Mon, Jul 25, 2011 at 10:14 PM, Greg Smith wrote:
>>> On 07/25/2011 04:07 PM, Robert Haas wrote:
I did 5-minute pgbench runs with unlogged tables and with permanent
tabl
On Tue, Jul 26, 2011 at 12:29 PM, Pavan Deolasee
wrote:
>
> So many transactions trying to update a small set of rows in a table.
> Is that what we really want to measure ? My thinking is that we might
> see different result if they are updating different parts of the table
> and the transaction
On Tue, Jul 26, 2011 at 12:24 PM, Robert Haas wrote:
> On Tue, Jul 26, 2011 at 11:40 AM, Pavan Deolasee
> wrote:
>> On Tue, Jul 26, 2011 at 9:07 AM, Robert Haas wrote:
>>> On Mon, Jul 25, 2011 at 10:14 PM, Greg Smith wrote:
On 07/25/2011 04:07 PM, Robert Haas wrote:
>
> I did 5-min
On Tue, Jul 26, 2011 at 11:40 AM, Pavan Deolasee
wrote:
> On Tue, Jul 26, 2011 at 9:07 AM, Robert Haas wrote:
>> On Mon, Jul 25, 2011 at 10:14 PM, Greg Smith wrote:
>>> On 07/25/2011 04:07 PM, Robert Haas wrote:
I did 5-minute pgbench runs with unlogged tables and with permanent
t
On Tue, Jul 26, 2011 at 9:07 AM, Robert Haas wrote:
> On Mon, Jul 25, 2011 at 10:14 PM, Greg Smith wrote:
>> On 07/25/2011 04:07 PM, Robert Haas wrote:
>>>
>>> I did 5-minute pgbench runs with unlogged tables and with permanent
>>> tables, restarting the database server and reinitializing the tab
On Mon, Jul 25, 2011 at 10:14 PM, Greg Smith wrote:
> On 07/25/2011 04:07 PM, Robert Haas wrote:
>>
>> I did 5-minute pgbench runs with unlogged tables and with permanent
>> tables, restarting the database server and reinitializing the tables
>> between each run.
>
> Database scale? One or multip
On 07/25/2011 04:07 PM, Robert Haas wrote:
I did 5-minute pgbench runs with unlogged tables and with permanent
tables, restarting the database server and reinitializing the tables
between each run.
Database scale? One or multiple pgbench worker threads? A reminder on
the amount of RAM in the
On Mon, Jul 25, 2011 at 4:07 PM, Robert Haas wrote:
> As to what that something might be, I reran this last test with
> LWLOCK_STATS enabled and here are the top things that are blocking:
>
> lwlock 310: shacq 96846 exacq 108433 blk 16275
> lwlock 3: shacq 64 exacq 2628381 blk 36027
> lwlock 7: sh
Excerpts from Merlin Moncure's message of lun jul 25 17:19:58 -0400 2011:
> On Mon, Jul 25, 2011 at 3:07 PM, Robert Haas wrote:
> > Experience
> > with the read scalability stuff has taught me also to look at which
> > LWLocks have the most shared acquisitions, as that can cause spinlock
> > and
On Mon, Jul 25, 2011 at 3:07 PM, Robert Haas wrote:
> I've long harbored a suspicion, based on some testing I did on my home
> machine, that WALInsertLock is a big performance bottleneck. But I
> just did some benchmarking that doesn't entirely support that
> contention. This is on Nate Boley's
I've long harbored a suspicion, based on some testing I did on my home
machine, that WALInsertLock is a big performance bottleneck. But I
just did some benchmarking that doesn't entirely support that
contention. This is on Nate Boley's 32-core machine, with the
following settings:
max_connection
12 matches
Mail list logo
