Hi,

I'm using Postgresql 8.1.3.

Recently I facing one problem, when the connection for postgresql grow up
to 45 or more, when I trigger a statement from WebApp
this statement will stuck forever.
I try to kill this transaction and then trigger the same statement again
but it still the same.
But this time I leave the transaction there and try to kill other
connections that is not in use.
It's weird that after I kill around 5-10 unused connections, the statement
start to run and finish.

Could anyone give me some idea how could this be?
Is it a bug of PostgreSQL?

This is the statement which having problem:
select count(distinct empno) as counter1 from pay_master_history
where empno in (select empno from pay_batch_basic_history where
organizationid like '015003%')
and processyear = '2006'
and processmonth = '05'
and processbatch = '1'

Thanks!


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

<kah_hang_ang (AT) toray (DOT) com.my> wrote
I can hardly believe that's Postgres's problem. Are you sure the query
was processing by the server? Try to do:

ps -auxw|grep postgres

to see if you can see the query was stuck there.

Regards,
Qingqing



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

------=_Part_1387_29406963.1149232138325
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

This is the statement which having problem:
select count(distinct empno) as counter1 from pay_master_history
where empno in (select empno from pay_batch_basic_history where
organizationid like '015003%')
and processyear = '2006'
and processmonth = '05'
and processbatch = '1'

SELECT COUNT (*) FROM (
SELECT empno as counter1 from pay_master_history as a
INNER JOIN (select empno from pay_batch_basic_history where organizationid
like '015003%' and processyear = '2006'
and processmonth = '05'
and processbatch = '1') as b
ON b.empno = a.empno ) as count_result
-----------------------------
or just create the view and use inner join then count :b

------=_Part_1387_29406963.1149232138325
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

This is the statement which having problem:<br> &nbsp; &nbsp; &nbsp;select count(distinct empno) as counter1 from pay_master_history<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;where empno in (select empno from pay_batch_basic_history where<br>organizationid like '015003%')
<br> &nbsp; &nbsp; &nbsp;and processyear = '2006'<br> &nbsp; &nbsp; &nbsp;and processmonth = '05'<br> &nbsp; &nbsp; &nbsp;and processbatch = '1'<br><br>SELECT COUNT (*) FROM (<br>SELECT empno as counter1 from pay_master_history as a<br>INNER JOIN (select empno from pay_batch_basic_history where organizationid like '015003%' &nbsp; &nbsp;&nbsp; and processyear = '2006'
<br>
&nbsp; &nbsp; &nbsp;and processmonth = '05'<br>
&nbsp; &nbsp; &nbsp;and processbatch = '1') as b<br>ON b.empno = a.empno ) as count_result<br>-----------------------------<br>or just create the view and use inner join then count :b<br>

------=_Part_1387_29406963.1149232138325--

I had check using ps -auxw|grep postgres & using select * from
pg_stat_activity
and it shows that the is really running and use 99% of the CPU.

Is there any wrong with the query?
As suggested by Jan Cruz, it is to fine tune the performance of the query.
Even if I not fine tune the query it should able to run without problem.

What I not understand is why this query stuck when the connection growth up
to certain limit.

I did try execute the query with the connection more than 45 and it really
stuck there.
I wait for around 10 minutes but it still running.
I kill about 10 connections then the query start to run and finish within
30 sec.

May I know what will be the possible cause of this problem?

Regards,
KH Ang




"Jan Cruz"
<malebug (AT) gmail (DOT) com> To: "Qingqing Zhou" <zhouqq (AT) cs (DOT) toronto.edu>
Sent by: cc: pgsql-bugs (AT) postgresql (DOT) org
pgsql-bugs-owner@pos Subject: Re: [BUGS] statement stuck when the connection grew up to 45 or more
tgresql.org


06/02/2006 03:08 PM






This is the statement which having problem:
select count(distinct empno) as counter1 from pay_master_history
where empno in (select empno from pay_batch_basic_history where
organizationid like '015003%')
and processyear = '2006'
and processmonth = '05'
and processbatch = '1'

SELECT COUNT (*) FROM (
SELECT empno as counter1 from pay_master_history as a
INNER JOIN (select empno from pay_batch_basic_history where organizationid
like '015003%' and processyear = '2006'
and processmonth = '05'
and processbatch = '1') as b
ON b.empno = a.empno ) as count_result
-----------------------------
or just create the view and use inner join then count :b



---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On Fri, Jun 09, 2006 at 05:29:08PM +0800, kah_hang_ang (AT) toray (DOT) com.my wrote:
Was the box swapping during this time? What are the specs on the
machine?

--
Jim C. Nasby, Sr. Engineering Consultant jnasby (AT) pervasive (DOT) com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Was the box swapping during this time?
No.

Spec for the machine:
AMD Opteron 2.4Ghz
4GB RAM
120G hard disk





"Jim C. Nasby"
<jnasby@pervasive To: kah_hang_ang (AT) toray (DOT) com.my
.com> cc: Jan Cruz <malebug (AT) gmail (DOT) com>, Qingqing Zhou <zhouqq (AT) cs (DOT) toronto.edu>,
pgsql-bugs (AT) postgresql (DOT) org
06/10/2006 01:33 Subject: Re: [BUGS] statement stuck when the connection grew up to 45 or more
AM






On Fri, Jun 09, 2006 at 05:29:08PM +0800, kah_hang_ang (AT) toray (DOT) com.my wrote:
Was the box swapping during this time? What are the specs on the
machine?


--
Jim C. Nasby, Sr. Engineering Consultant jnasby (AT) pervasive (DOT) com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461




---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly