Re: Performance degredation at client site - Mailing list pgsql-performance

From Bill Chandler
Subject Re: Performance degredation at client site
Date
Msg-id 20050131183200.59937.qmail@web51404.mail.yahoo.com
Whole thread Raw
In response to Re: Performance degredation at client site  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
Tom,

Thank you!  I will have the client try that.  What
about the event_tbl_evt_id_key index question.  Could
that also be causing me difficulties?  Should I
periodically reindex it?

thanks,

Bill

--- Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Bill Chandler <billybobc1210@yahoo.com> writes:
> > Update processes run continually throughout the
> day in
> > which rows are inserted but none deleted.
>
> What about row updates?
>
> > Even seemingly simple commands are taking forever.
>
> > For example:
> > select evt_id from event_tbl where evt_id=1;
> > takes over a minute to complete.
>
> Since evt_id is a bigint, you need to write that as
>
> select evt_id from event_tbl where evt_id=1::bigint;
>
> or various other locutions that have the same
> effect.  What you have is
> a bigint-vs-int comparison, which is not indexable
> in releases before 8.0.
>
> The same problem is occurring in your other example.
>
>             regards, tom lane
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

pgsql-performance by date:

Previous
From: PFC
Date:
Subject: Re: Performance degredation at client site
Next
From: Josh Berkus
Date:
Subject: Re: Automagic tuning