Gregory Stark wrote:
Incidentally we found some cases that Solaris was particularly bad at. Is
there anybody in particular that would be interested in hearing about them?
(Not meant to be a knock on Solaris, I'm sure there are other cases Linux or
BSD handle poorly too)
Send me the detai
TPC-H has two runs
PowerRun which is single stream (Q1-22 RF1, RF2)
And Throughput Runs which has "N" (depends on scale) running
simultaneously in a mixed sequence of the same queries and the two
update functions. During throughput run you can expect to max out CPU...
But commerial databases g
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
> Also very important unless you are running the UPDATE FUNCTIONS which are
> separate queries, all these Q1-Q22 Queries are pure "READ-ONLY" queries.
> Traditionally I think PostgreSQL does lack "READ-SPEED"s specially since it is
> bottlenecked by t
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
> Then for the power run that is essentially running one query at a time should
> essentially be able to utilize the full system (specially multi-core systems),
> unfortunately PostgreSQL can use only one core. (Plus since this is read only
> and ther
On Mon, 4 Feb 2008, Jignesh K. Shah wrote:
Doing it at low scales is not attractive. Commercial databases are
publishing at scale factor of 1000(about 1TB) to 1(10TB) with one in
30TB space. So ideally right now tuning should start at 1000 scale
factor.
I think what Simon was trying to
Doing it at low scales is not attractive.
Commercial databases are publishing at scale factor of 1000(about 1TB)
to 1(10TB) with one in 30TB space. So ideally right now tuning
should start at 1000 scale factor.
Unfortunately I have tried that before with PostgreSQL the few of the
problem
On Mon, 4 Feb 2008, Luke Lonergan wrote:
However, I think you can use their published data and query generation kit
to run the queries, which aren't the benchmark per-se. That's what the
Monet/X100 people did.
Right; I was just hoping someone might suggest some relatively
standardized way to
Hi Simon,
I have some insight into TPC-H on how it works.
First of all I think it is a violation of TPC rules to publish numbers
without auditing them first. So even if I do the test to show the
better performance of PostgreSQL 8.3, I cannot post it here or any
public forum without doing goi
Hi Greg,
On 2/4/08 12:09 PM, "Greg Smith" <[EMAIL PROTECTED]> wrote:
> Do you have any suggestions on how people should run TPC-H? It looked
> like a bit of work to sort through how to even start this exercise.
To run "TPC-H" requires a license to publish, etc.
However, I think you can use the
Hi Simon,
On 2/4/08 11:07 AM, "Simon Riggs" <[EMAIL PROTECTED]> wrote:
>> "executor-executor" test and we/you should be sure that the PG planner has
>> generated the best possible plan.
>
> If it doesn't then I'd regard that as a performance issue in itself.
Agreed, though that's two problems t
On Mon, 2008-02-04 at 15:09 -0500, Greg Smith wrote:
> On Mon, 4 Feb 2008, Simon Riggs wrote:
>
> > Would anybody like to repeat these tests with the latest production
> > versions of these databases (i.e. with PGSQL 8.3)
>
> Do you have any suggestions on how people should run TPC-H? It looked
On Mon, 4 Feb 2008, Simon Riggs wrote:
Would anybody like to repeat these tests with the latest production
versions of these databases (i.e. with PGSQL 8.3)
Do you have any suggestions on how people should run TPC-H? It looked
like a bit of work to sort through how to even start this exercis
On Mon, 2008-02-04 at 10:47 -0800, Luke Lonergan wrote:
> Note that MonetDB/X100 does not have a SQL optimizer, they ran raw
> hand-coded plans. As a consequence, these comparisons should be taken as an
> "executor-executor" test and we/you should be sure that the PG planner has
> generated the b
> There are some results here that show PostgreSQL is slower in some cases
> than Monet and MySQL. Of course these results were published immediately
> prior to 8.2 being released, plus run out-of-the-box, so without even
> basic performance tuning.
>
> Would anybody like to repeat these tests with
Hi Simon,
Note that MonetDB/X100 does not have a SQL optimizer, they ran raw
hand-coded plans. As a consequence, these comparisons should be taken as an
"executor-executor" test and we/you should be sure that the PG planner has
generated the best possible plan.
That said, we've already done the
Can I ask for some help with benchmarking?
There are some results here that show PostgreSQL is slower in some cases
than Monet and MySQL. Of course these results were published immediately
prior to 8.2 being released, plus run out-of-the-box, so without even
basic performance tuning.
Would anybod
16 matches
Mail list logo
