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

Re: Performance degredation at client site

From: Bill Chandler <billybobc1210(at)yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Performance degredation at client site
Date: 2005-01-31 18:32:00
Message-ID: 20050131183200.59937.qmail@web51404.mail.yahoo.com (view raw or flat)
Thread:
Lists: 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(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Bill Chandler <billybobc1210(at)yahoo(dot)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 

In response to

pgsql-performance by date

Next:From: Josh BerkusDate: 2005-01-31 20:09:31
Subject: Re: Automagic tuning
Previous:From: PFCDate: 2005-01-31 18:14:48
Subject: Re: Performance degredation at client site

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