On Jan 10, 2012, at 3:16 AM, Simon Riggs wrote:
> On Tue, Jan 10, 2012 at 12:24 AM, Jim Nasby wrote:
>> IIRC, pg_bench is *extremely* write-heavy. There's probably not that many
>> systems that operate that way. I suspect that most OLTP systems read more
>> than they write, and some probably hav
On Tue, Jan 10, 2012 at 3:16 AM, Simon Riggs wrote:
> So benchmarking write-heavy workloads and separately benchmarking
> read-only workloads is more representative.
Absolutely. High write activity applications are much more difficult
to optimize with simple tricks like client side caching. Als
On Tue, Jan 10, 2012 at 12:24 AM, Jim Nasby wrote:
> IIRC, pg_bench is *extremely* write-heavy. There's probably not that many
> systems that operate that way. I suspect that most OLTP systems read more
> than they write, and some probably have as much as a 10-1 ratio.
IMHO the main PostgreSQL
On Mon, Jan 9, 2012 at 7:24 PM, Jim Nasby wrote:
> On Jan 6, 2012, at 8:40 PM, Robert Haas wrote:
Somewhat depressingly,
virtually all of the interesting activity still centers around the
same three locks that were problematic back then, which means that -
although overall per
On Jan 6, 2012, at 8:40 PM, Robert Haas wrote:
>>> Somewhat depressingly,
>>> virtually all of the interesting activity still centers around the
>>> same three locks that were problematic back then, which means that -
>>> although overall performance has improved quite a bit - we've not
>>> really
On Sat, Jan 7, 2012 at 5:24 AM, Simon Riggs wrote:
> On Fri, Jan 6, 2012 at 10:24 PM, Robert Haas wrote:
>> Five-minute pgbench run, scale factor 100,
>> permanent tables, my usual config settings. Somewhat depressingly,
>> virtually all of the interesting activity still centers around the
>> s
On 07.01.2012 19:18, Tom Lane wrote:
Heikki Linnakangas writes:
A couple of weeks ago I wrote a little patch that's similar to
LWLOCK_STATS, but it prints out % of wallclock time that is spent
acquiring, releasing, or waiting for a lock. I find that more useful
than the counters.
I would thin
Heikki Linnakangas writes:
> A couple of weeks ago I wrote a little patch that's similar to
> LWLOCK_STATS, but it prints out % of wallclock time that is spent
> acquiring, releasing, or waiting for a lock. I find that more useful
> than the counters.
I would think that the measurement overhea
2012/01/07 16:58, Heikki Linnakangas wrote:
On 07.01.2012 00:24, Robert Haas wrote:
It's been a while since I did any testing with LWLOCK_STATS defined,
so I thought it might be about time to do that again and see how
things look. Here's how they looked back in July:
http://archives.postgresql.
On Fri, Jan 6, 2012 at 10:24 PM, Robert Haas wrote:
> Five-minute pgbench run, scale factor 100,
> permanent tables, my usual config settings. Somewhat depressingly,
> virtually all of the interesting activity still centers around the
> same three locks
We've seen clear evidence that the perfo
On 07.01.2012 09:58, Heikki Linnakangas wrote:
Here's the patch,
*sigh*, and here's the forgotten attachment.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
diff --git a/src/backend/storage/lmgr/lwlock.c b/src/backend/storage/lmgr/lwlock.c
index 079eb29..c38a884 100644
--
On 07.01.2012 00:24, Robert Haas wrote:
It's been a while since I did any testing with LWLOCK_STATS defined,
so I thought it might be about time to do that again and see how
things look. Here's how they looked back in July:
http://archives.postgresql.org/pgsql-hackers/2011-07/msg01373.php
Int
On Fri, Jan 6, 2012 at 9:29 PM, Jeff Janes wrote:
> On Fri, Jan 6, 2012 at 2:24 PM, Robert Haas wrote:
>> It's been a while since I did any testing with LWLOCK_STATS defined,
>> so I thought it might be about time to do that again and see how
>> things look. Here's how they looked back in July:
On Fri, Jan 6, 2012 at 2:24 PM, Robert Haas wrote:
> It's been a while since I did any testing with LWLOCK_STATS defined,
> so I thought it might be about time to do that again and see how
> things look. Here's how they looked back in July:
>
> http://archives.postgresql.org/pgsql-hackers/2011-07
14 matches
Mail list logo
