Re: Any better plan for this query?..

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 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!
-Dimitri

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 www.2ndQuadrant.com
> PostgreSQL Training, Services and Support
>
>