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

Re: Slow response of PostgreSQL

From: Shridhar Daithankar <shridhar(at)frodo(dot)hserus(dot)net>
To: "Saleem Burhani Baloch" <peseek(at)khi(dot)wol(dot)net(dot)pk>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Slow response of PostgreSQL
Date: 2004-02-19 09:26:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Thursday 19 February 2004 14:31, Saleem Burhani Baloch wrote:
> Hi,
> Thanks every one for helping me. I have upgraded to 7.4.1 on redhat 8 ( rh
> 9 require a lot of lib's) and set the configuration sent by Chris. Now the
> query results in 6.3 sec waooo. I m thinking that why the 7.1 process
> aggregate slowly. Anyway.
> I still have to go for 2 sec result and now I m thinking to go for Free BSD
> 5.2.

Before that you can try something with kernel 2.6.3. I think it could make the 
difference you are looking at.

> The record locking by "select ..... update for" is working fine, but a
> situation arrises when the second user goes for locking the record,  the
> task will wait untill the first user ends up his work. IS their is a way
> that we can know or get a message that the row/record is already locked by
> some one else.

Right now, it is hotly debated on HACKERS about adding a NOWAIT clause to 
SELECT FOR UPDATE. If you think your application deployment is away for 
months and can try CVS head, you can expect some action on it in coming few 

As a side bonus you would be benefitted by performance and scalability 
additions that won't make there way in 7.4 stream.



In response to


pgsql-performance by date

Next:From: Christopher Kings-LynneDate: 2004-02-19 13:52:48
Subject: Re: Slow response of PostgreSQL
Previous:From: Saleem Burhani BalochDate: 2004-02-19 09:01:20
Subject: Re: Slow response of PostgreSQL

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