Re: osdl-dbt3 run results - puzzled by the execution plans

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jenny Zhang <jenny(at)osdl(dot)org>, pgsql-performance(at)postgresql(dot)org
Subject: Re: osdl-dbt3 run results - puzzled by the execution plans
Date: 2003-09-19 13:12:27
Message-ID: 87fzis2a84.fsf@stark.dyndns.tv
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance


Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> I think this is a pipe dream. Variation in where the data gets laid
> down on your disk drive would alone create more than that kind of delta.
> I'm frankly amazed you could get repeatability within 2-3%.

I think the reason he gets good repeatability is because he's talking about
the aggregate results for a whole test run. Not individual queries. In theory
you could just run the whole test multiple times. The more times you run it
the lower the variation in the total run time would be.

Actually, the variation in run time is also a useful statistic, both for
postgres and the kernel. It might be useful to do multiple complete runs and
keep track of the average standard deviation of the time required for each
step.

Higher standard deviation implies queries can't be reliably depended on not to
take inordinately long, which can be a problem for some working models. For
the kernel it could mean latency issues or it could mean the swapper or buffer
cache was overly aggressive.

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gaetano Mendola 2003-09-19 13:38:33 Re: 7.4beta2 vs 7.3.3
Previous Message Marc G. Fournier 2003-09-19 13:06:23 Re: NuSphere and PostgreSQL for windows

Browse pgsql-performance by date

  From Date Subject
Next Message Manfred Koizar 2003-09-19 15:08:26 Re: osdl-dbt3 run results - puzzled by the execution plans
Previous Message Matt Clark 2003-09-19 10:41:55 Re: osdl-dbt3 run results - puzzled by the execution