On Mon, Feb 6, 2012 at 6:38 AM, Robert Haas wrote:
> On Sat, Feb 4, 2012 at 2:13 PM, Jeff Janes wrote:
>> We really need to nail that down. Could you post the scripts (on the
>> wiki) you use for running the benchmark and making the graph? I'd
>> like to see how much work it would be for me to
On 01/24/2012 03:53 PM, Robert Haas wrote:
There are two graphs for each branch. The first is a scatter plot of
latency vs. transaction time. I found that graph hard to understand,
though; I couldn't really tell what I was looking at. So I made a
second set of graphs which graph number of comp
On Sat, Feb 4, 2012 at 2:13 PM, Jeff Janes wrote:
> We really need to nail that down. Could you post the scripts (on the
> wiki) you use for running the benchmark and making the graph? I'd
> like to see how much work it would be for me to change it to detect
> checkpoints and do something like c
On Wed, Feb 1, 2012 at 9:47 AM, Robert Haas wrote:
> On Wed, Jan 25, 2012 at 8:49 AM, Robert Haas wrote:
>> On Tue, Jan 24, 2012 at 4:28 PM, Simon Riggs wrote:
>>> I think we should be working to commit XLogInsert and then Group
>>> Commit, then come back to the discussion.
>>
>> I definitely ag
Robert Haas wrote:
> A couple of things stand out at me from these graphs. First, some
> of these transactions had really long latency. Second, there are a
> remarkable number of seconds all of the test during which no
> transactions at all manage to complete, sometimes several seconds
> in a ro
On Wed, Feb 1, 2012 at 5:47 PM, Robert Haas wrote:
> On Wed, Jan 25, 2012 at 8:49 AM, Robert Haas wrote:
>> On Tue, Jan 24, 2012 at 4:28 PM, Simon Riggs wrote:
>>> I think we should be working to commit XLogInsert and then Group
>>> Commit, then come back to the discussion.
>>
>> I definitely ag
On Wed, Jan 25, 2012 at 8:49 AM, Robert Haas wrote:
> On Tue, Jan 24, 2012 at 4:28 PM, Simon Riggs wrote:
>> I think we should be working to commit XLogInsert and then Group
>> Commit, then come back to the discussion.
>
> I definitely agree that those two have way more promise than anything
> el
> I actually don't know much about the I/O subsystem, but, no, WAL is
> not separated from data. I believe $PGDATA is on a SAN, but I don't
> know anything about its characteristics.
The computer is here:
http://www.supermicro.nl/Aplus/system/2U/2042/AS-2042G-6RF.cfm
$PGDATA is on a 5 disk SATA
On Wed, Jan 25, 2012 at 12:00 PM, Jeff Janes wrote:
> On Tue, Jan 24, 2012 at 12:53 PM, Robert Haas wrote:
>> Early yesterday morning, I was able to use Nate Boley's test machine
>> do a single 30-minute pgbench run at scale factor 300 using a variety
>> of trees built with various patches, and w
On Wed, Jan 25, 2012 at 9:09 AM, Robert Haas wrote:
> On Wed, Jan 25, 2012 at 12:00 PM, Jeff Janes wrote:
>> On Tue, Jan 24, 2012 at 12:53 PM, Robert Haas wrote:
>>> Early yesterday morning, I was able to use Nate Boley's test machine
>>> do a single 30-minute pgbench run at scale factor 300 usi
On Tue, Jan 24, 2012 at 12:53 PM, Robert Haas wrote:
> Early yesterday morning, I was able to use Nate Boley's test machine
> do a single 30-minute pgbench run at scale factor 300 using a variety
> of trees built with various patches, and with the -l option added to
> track latency on a per-transa
On Tue, Jan 24, 2012 at 4:28 PM, Simon Riggs wrote:
> I think we should be working to commit XLogInsert and then Group
> Commit, then come back to the discussion.
I definitely agree that those two have way more promise than anything
else on the table. However, now that I understand how badly we'
On Wed, Jan 25, 2012 at 2:23 AM, Robert Haas wrote:
> Early yesterday morning, I was able to use Nate Boley's test machine
> do a single 30-minute pgbench run at scale factor 300 using a variety
> of trees built with various patches, and with the -l option added to
> track latency on a per-transac
On Tue, Jan 24, 2012 at 8:53 PM, Robert Haas wrote:
>
> do a single 30-minute pgbench run at scale factor 300 using a variety
Nice
A minor but necessary point: Repeated testing of the Group commit
patch when you have synch commit off is clearly pointless, so
publishing numbers for that without s
Early yesterday morning, I was able to use Nate Boley's test machine
do a single 30-minute pgbench run at scale factor 300 using a variety
of trees built with various patches, and with the -l option added to
track latency on a per-transaction basis. All tests were done using
32 clients and permane
15 matches
Mail list logo