Обсуждение: data corruption

Поиск
Список
Период
Сортировка

data corruption

От
Hemapriya
Дата:
Hi,

I have a query that runs fine for one set of data and
not for another.

In the following query, all the columns used in a
where
clause are indexed. If i use this for the
origindbs('02','05','06','07') except '04', it works
fine.
when i look for the data from origindb "04" it just
run for 2 hours.

"select count(*) from qpassextrequest a,request b
where a.requestFK=b.uid and a.origindb='04' and
a.origindb=b.origindb and b.enteredon >='2005-09-28'
and b.enteredon < '2005-09-29'"

What could be the reason.. Can that be a index or data
corruption? If so, rebuiding the index will solve the
problem?

Any hint is appreciated.

Thanks
Priya





__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com

Re: data corruption

От
Gourish Singbal
Дата:
 
priya,
 
I would suggest do a vacuum full analyze verbose <tablename> on both the tables.
and than explain analyze <query> command to check if proper indexes are been used.
 
regards
gourish singbal
 
On 9/29/05, Hemapriya <priyam_1121@yahoo.com> wrote:
Hi,

I have a query that runs fine for one set of data and
not for another.

In the following query, all the columns used in a
where
clause are indexed. If i use this for the
origindbs('02','05','06','07') except '04', it works
fine.
when i look for the data from origindb "04" it just
run for 2 hours.

"select count(*) from qpassextrequest a,request b
where a.requestFK=b.uid and a.origindb='04' and
a.origindb=b.origindb and b.enteredon >='2005-09-28'
and b.enteredon < '2005-09-29'"

What could be the reason.. Can that be a index or data
corruption? If so, rebuiding the index will solve the
problem?

Any hint is appreciated.

Thanks
Priya





__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

              http://archives.postgresql.org



--
Best,
Gourish Singbal