Re: [HACKERS] Stored procedure issue

From: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
To: "Dragan Zubac" <moroncic(at)yahoo(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org
Subject: Re: [HACKERS] Stored procedure issue
Date: 2007-12-03 13:24:57
Message-ID: 162867790712030524g4bed2921t2d6fd400d44edb67@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Hello

On 03/12/2007, Dragan Zubac <moroncic(at)yahoo(dot)com> wrote:
> Hello
>
> What I have noticed is that when I don't use procedure
> at all,there's only 2-5 locks in pg_locks,after I
> start application which uses stored procedure the
> number in pg_locks increase rapidly to steady 75 even
> to 130 at certain moments.
>
> Any clue why procedure usage might increase locks so
> heavily ?
>
> Sincerely
>

upgrade to 8.2? There is shared lock and there are less problems with
locks. But I am not sure if this solves your problem. General
protection before locks is all things with maximal speed. Are your
queris well optimazed?

Regards
Pavel Stehule

> --- Dragan Zubac <moroncic(at)yahoo(dot)com> wrote:
>
> > Hello
> >
> > I have a stored procedure which does the billing
> > stuff
> > in our system,it works ok,but if I put in
> > production,where there is some 5-10 billing events
> > per
> > second,the whole database slows down. It won't even
> > drop some test table,reindex,vacuum,things which
> > were
> > done before in the blink of an eye. If I stop the
> > application which calls the procedure,all is back to
> > normal.
> >
> > We didn't implement any special locking mechanism in
> > the procedure,all is default. The procedure is
> > updating user's balance in table 'users'. On the
> > other
> > hand a couple of 'heavy load' table has foreign keys
> > pointing to table 'users'.
> >
> > Is it the matter of concurency and some locking
> > issue
> > or maybe the existing of all those foreign keys
> > pointing to table 'users',or maybe something else
> > which we're not aware at the moment ?
> >
> > Sincerely
> >
> > Pera
> >
> >
> >
> >
> ____________________________________________________________________________________
> > Be a better sports nut! Let your teams follow you
> > with Yahoo Mobile. Try it now.
> >
> http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ
> >
> > ---------------------------(end of
> > broadcast)---------------------------
> > TIP 7: You can help support the PostgreSQL project
> > by donating at
> >
> >
> > http://www.postgresql.org/about/donate
> >
>
>
>
> ____________________________________________________________________________________
> Be a better friend, newshound, and
> know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>
>
> ---------------------------(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
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Marko Kreen 2007-12-03 13:27:11 Re: pgcrypto functions fail for asymmetric encryption/decryption
Previous Message Dragan Zubac 2007-12-03 12:16:02 Re: [HACKERS] Stored procedure issue

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-12-03 15:52:15 Re: buildenv.pl/buildenv.bat
Previous Message Alvaro Herrera 2007-12-03 12:21:26 Re: Regression testing