In response to "Jim C. Nasby" <[EMAIL PROTECTED]>:
> On Thu, Sep 28, 2006 at 11:28:43AM -0400, Bill Moran wrote:
> > In response to Matthew Schumacher <[EMAIL PROTECTED]>:
> > >
> > > What I really need is a way to profile my proc when it runs slow so that
> > > I can resolve which of the queries
On Thu, Sep 28, 2006 at 11:28:43AM -0400, Bill Moran wrote:
> In response to Matthew Schumacher <[EMAIL PROTECTED]>:
> >
> > What I really need is a way to profile my proc when it runs slow so that
> > I can resolve which of the queries is really slow. Anyone with an idea
> > on how to do this?
>
In response to Matthew Schumacher <[EMAIL PROTECTED]>:
>
> What I really need is a way to profile my proc when it runs slow so that
> I can resolve which of the queries is really slow. Anyone with an idea
> on how to do this?
You could turn on statement logging and duration logging. This would
Marcin Mank wrote:
>> So the question is why on a relatively simple proc and I getting a query
>> performance delta between 3549ms and 7ms?
>
> What version of PG is it?
>
> I had such problems in a pseudo-realtime app I use here with Postgres, and
> they went away when I moved to 8.1 (from 7.4).
> So the question is why on a relatively simple proc and I getting a query
> performance delta between 3549ms and 7ms?
What version of PG is it?
I had such problems in a pseudo-realtime app I use here with Postgres, and
they went away when I moved to 8.1 (from 7.4). I guess it is better shared
bu
On Wed, Sep 27, 2006 at 02:17:23PM -0800, Matthew Schumacher wrote:
> Jim C. Nasby wrote:
> >
> > It can cause a race if another process could be performing those same
> > inserts or updates at the same time.
>
> There are inserts and updates running all of the time, but never the
> same data.
Jim C. Nasby wrote:
>
> It can cause a race if another process could be performing those same
> inserts or updates at the same time.
There are inserts and updates running all of the time, but never the
same data. I'm not sure how I can get around this since the queries are
coming from my radius
On Wed, Sep 27, 2006 at 01:33:09PM -0800, Matthew Schumacher wrote:
> Jim,
>
> Thanks for the help. I went and looked at that example and I don't see
> how it's different than the "INSERT into radutmp_tab" I'm already doing.
> Both raise an exception, the only difference is that I'm not doing
>
Jim,
Thanks for the help. I went and looked at that example and I don't see
how it's different than the "INSERT into radutmp_tab" I'm already doing.
Both raise an exception, the only difference is that I'm not doing
anything with it. Perhaps you are talking about the "IF (NOT FOUND)" I
put afte
Periodically taking longer is probably a case of some other process in
the database holding a lock you need, or otherwise bogging the system
down, especially if you're always running acctmessage from the same
connection (because the query plans shouldn't be changing then). I'd
suggest looking at wh
List,
I posted a little about this a while back to the general list, but never
really got any where with it so I'll try again, this time with a little
more detail and hopefully someone can send me in the right direction.
Here is the problem, I have a procedure that is called 100k times a day.
Mo
11 matches
Mail list logo
