Skip site navigation (1) Skip section navigation (2)

Re: Any better plan for this query?..

From: Dimitri <dimitrik(dot)fr(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Any better plan for this query?..
Date: 2009-05-18 18:00:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Folks, I've just published a full report including all results here:

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).

Then to investigate on scalability issue I think a bigger server will
be needed here (I'm looking for 64cores at least :-))

If  you have some other ideas or patches (like Simon) - don't hesitate
to send them - once I'll get an access to the server again the
available test time will be very limited..

Best regards!

On 5/18/09, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Thu, 2009-05-14 at 20:25 +0200, Dimitri wrote:
>> # lwlock_wait_8.4.d `pgrep -n postgres`
>>                Lock Id            Mode   Combined Time (ns)
>>       FirstLockMgrLock       Exclusive                 803700
>>        BufFreelistLock       Exclusive                 3001600
>>       FirstLockMgrLock          Shared               4586600
>>  FirstBufMappingLock       Exclusive              6283900
>>  FirstBufMappingLock          Shared             21792900
> I've published two patches to -Hackers to see if we can improve the read
> only numbers on 32+ cores.
> Try shared_buffer_partitions = 256
> --
>  Simon Riggs 
>  PostgreSQL Training, Services and Support

In response to


pgsql-performance by date

Next:From: Simon RiggsDate: 2009-05-18 19:27:34
Subject: Re: Any better plan for this query?..
Previous:From: Simon RiggsDate: 2009-05-18 15:10:20
Subject: Re: Any better plan for this query?..

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group