On 5/18/09 3:32 PM, "Dimitri" wrote:
> On 5/18/09, Scott Carey wrote:
>> Great data Dimitri!'
>
> Thank you! :-)
>
>>
>> I see a few key trends in the poor scalability:
>>
>> The throughput scales roughly with %CPU fairly well. But CPU used doesn't
>> go past ~50% on the 32 core tests. Th
Simon Riggs writes:
> In particular, running the tests repeatedly using
> H.REF_OBJECT = '01'
> rather than varying the value seems likely to benefit MySQL.
... mumble ... query cache?
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql-pe
On 5/18/09, Simon Riggs wrote:
>
> On Mon, 2009-05-18 at 20:00 +0200, Dimitri wrote:
>
>> >From my point of view it needs first to understand where the time is
>> wasted on a single query (even when the statement is prepared it runs
>> still slower comparing to MySQL).
>
> There is still a signifi
On 5/18/09, Scott Carey wrote:
> Great data Dimitri!'
Thank you! :-)
>
> I see a few key trends in the poor scalability:
>
> The throughput scales roughly with %CPU fairly well. But CPU used doesn't
> go past ~50% on the 32 core tests. This indicates lock contention.
>
You should not look on
Thanks Dave for correction, but I'm also curious where the time is
wasted in this case?..
0.84ms is displayed by "psql" once the result output is printed, and I
got similar time within my client (using libpq) which is not printing
any output..
Rgds,
-Dimitri
On 5/18/09, Dave Dutcher wrote:
>
>
What I don't understand is the part where you talking about disabling hash
joins:
>* result: planner replaced hash join is replaced by merge join
>* execution time: 0.84ms !
>* NOTE: curiously planner is expecting to execute this query in 0.29ms
- so it's supposed from its logic to be
Great data Dimitri!'
I see a few key trends in the poor scalability:
The throughput scales roughly with %CPU fairly well. But CPU used doesn't
go past ~50% on the 32 core tests. This indicates lock contention.
Other proof of lock contention are the mutex locks / sec graph which climbs
rapidly
On Mon, 2009-05-18 at 20:00 +0200, Dimitri wrote:
> >From my point of view it needs first to understand where the time is
> wasted on a single query (even when the statement is prepared it runs
> still slower comparing to MySQL).
There is still a significant number of things to say about these n
Folks, I've just published a full report including all results here:
http://dimitrik.free.fr/db_STRESS_PostgreSQL_837_and_84_May2009.html
>From my point of view it needs first to understand where the time is
wasted on a single query (even when the statement is prepared it runs
still slower compari
On Wed, 2009-05-13 at 23:23 +0200, Dimitri Fontaine wrote:
> As I think I need this solution too, I've coded a PG module to
> scratch
> that itch this morning, and just published it (BSD licenced) on
> pgfoundry:
>http://preprepare.projects.postgresql.org/README.html
>http://cvs.pgfou
On Thu, 2009-05-14 at 20:25 +0200, Dimitri wrote:
> # lwlock_wait_8.4.d `pgrep -n postgres`
>Lock IdMode Combined Time (ns)
> FirstLockMgrLock Exclusive 803700
>BufFreelistLock Exclusive 3001600
> First
11 matches
Mail list logo
