Re: dbt3 data with 10GB scale factor

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Mark Wong <markw(at)osdl(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org, testperf-general(at)pgfoundry(dot)org, maryedie(at)osdl(dot)org
Subject: Re: dbt3 data with 10GB scale factor
Date: 2005-08-04 06:54:27
Message-ID: 1123138467.3670.369.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2005-08-02 at 14:22 -0700, Mark Wong wrote:
> I've started scaling dbt3 up to the 10GB scale factor against CVS and
> the fast COPY patch:
>
> http://www.testing.osdl.org/projects/dbt3testing/results/dev4-010/53/

Try "www1" if this URL fails for you.

> I'm sure there are some better database parameters I should use so
> please let me know what to try. ;) What I've found interesting is the
> difference in the time it takes for Q9 to run in the power test than the
> throughput test:
>
> Power Test 00:56:27
> Throughput Stream 1 00:38:13
> Throughput Stream 2 00:41:33
> Throughput Stream 3 00:20:16
> Throughput Stream 4 00:18:11
>
> Diffing the query plans between the Power Test and the individual
> streams in the Throughput Test, I only see a Materialize and Seq Scan on
> the nation table versus just a Seq Scan on the nation table between two
> of the plans. But this doesn't appear to account for the execution time
> difference as the query with the same plan executes just as fast during
> the Throughput Test. Here are the plans in full:

Very interesting. Excellent work on the test results.

Initial reaction was shock, but: most of these plans use nested joins,
so there's lots of shared_buffers work going on. It feels like this
would allow the queries to share a certain percentage of blocks and
allow the multiple backends to parallelise the I/O, which in the Power
test would all be single streamed.

Difference in plans? Well, they are actually all different queries, just
very similar. I note that the number of rows retrieved by the Power Test
query actually had the fewest number of rows of any query, so the time
difference might well have been much greater.

I'll look more into the plan differences.

Best Regards, Simon Riggs

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Qingqing Zhou 2005-08-04 08:19:44 Re: Fundamental error in "no WAL log" index/file
Previous Message Simon Riggs 2005-08-04 06:35:46 Re: Fundamental error in "no WAL log" index/file