Re: Joel's Performance Issues WAS : Opteron vs Xeon - Mailing list pgsql-performance

From John A Meinel
Subject Re: Joel's Performance Issues WAS : Opteron vs Xeon
Date
Msg-id 4266F7B3.7050004@arbash-meinel.com
Whole thread Raw
In response to Re: Joel's Performance Issues WAS : Opteron vs Xeon  ("Joel Fradkin" <jfradkin@wazagua.com>)
Responses Re: Joel's Performance Issues WAS : Opteron vs Xeon
Re: Joel's Performance Issues WAS : Opteron vs Xeon
List pgsql-performance
Joel Fradkin wrote:

>I did think of something similar just loading the data tables with junk
>records and I may visit that idea with Josh.
>
>I did just do some comparisons on timing of a plain select * from tbl where
>indexed column = x and it was considerably slower then both MSSQL and MYSQL,
>so I am still a bit confused. This still might be configuration issue (I ran
>on my 2gig desktop and the 8 gig Linux box comparisons were all ran on the
>same machines as far MSSQL, MYSQL, and Postgres.
>I turned off postgres when running MYSQL and turned off MYSQL when running
>postgres, MSSQL had one of the two running while I tested it.
>
>For the 360,000 records returned MYSQL did it in 40 seconds first run and 17
>seconds second run.
>
>MSSQL did it in 56 seconds first run and 16 seconds second run.
>
>Postgres was on the second run
>Total query runtime: 17109 ms.
>Data retrieval runtime: 72188 ms.
>331640 rows retrieved.
>
>So like 89 on the second run.
>The first run was 147 secs all told.
>
>These are all on my 2 meg desktop running XP.
>I can post the config. I noticed the postgres was using 70% of the cpu while
>MSSQL was 100%.
>
>Joel Fradkin
>
>
Why is MYSQL returning 360,000 rows, while Postgres is only returning
330,000? This may not be important at all, though.
I also assume you are selecting from a plain table, not a view.

I suppose knowing your work_mem, and shared_buffers settings would be
useful.

How were you measuring "data retrieval time"? And how does this compare
to what you were measuring on the other machines? It might be possible
that what you are really measuring is just the time it takes psql to
load up all the data into memory, and then print it out. And since psql
defaults to measuring entry lengths for each column, this may not be
truly comparable.
It *looks* like it only takes 18s for postgres to get the data, but then
it is taking 72s to transfer the data to you. That would be network
latency, or something like that, not database latency.
And I would say that 18s is very close to 16 or 17 seconds.

I don't know what commands you were issuing, or how you measured,
though. You might be using some other interface (like ODBC), which I
can't say too much about.

John
=:->



Attachment

pgsql-performance by date:

Previous
From: "Joel Fradkin"
Date:
Subject: Re: Joel's Performance Issues WAS : Opteron vs Xeon
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: immutable functions vs. join for lookups ?