On Apr 16, 2004, at 4:23 AM, Rajesh Kumar Mallah wrote:
I am running an update on the same table
update rfis set inquiry_status='APPROVED' where inquiry_status='a';
Its running for past 20 mins. and top output is below.
The PID which is executing the query above is 6712. Can anyone
tell m
link of pgsql_tmp to another parttion to successfully
complete.
Dan.
-Original Message-
From: Bill Moran [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 15, 2004 4:14 PM
To: Shea,Dan [CIS]
Cc: Postgres Performance
Subject: Re: [PERFORM] [ SOLVED ] select count(*) very slow on an
already
I am running an update on the same table
update rfis set inquiry_status='APPROVED' where inquiry_status='a';
Its running for past 20 mins. and top output is below.
The PID which is executing the query above is 6712. Can anyone
tell me why it is in an uninterruptable sleep and does it relat
Shea,Dan [CIS] wrote:
Bill, if you had alot of updates and deletions and wanted to optimize your
table, can you just issue the cluster command.
Will the cluster command rewrite the table without the obsolete data that a
vacuum flags or do you need to issue a vacuum first?
From the reference docs:
Moran [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 15, 2004 2:49 PM
To: Rajesh Kumar Mallah
Cc: Postgres Performance
Subject: Re: [PERFORM] [ SOLVED ] select count(*) very slow on an
already
Rajesh Kumar Mallah wrote:
> Bill Moran wrote:
>
>> Rajesh Kumar Mallah wrote:
>>
&
Rajesh Kumar Mallah wrote:
Bill Moran wrote:
Rajesh Kumar Mallah wrote:
Hi,
The problem was solved by reloading the Table.
the query now takes only 3 seconds. But that is
not a solution.
If dropping/recreating the table improves things, then we can reasonably
assume that the table is pretty acti
On Apr 15, 2004, at 12:44 PM, Richard Huxton wrote:
On Thursday 15 April 2004 17:19, Rajesh Kumar Mallah wrote:
Bill Moran wrote:
BTW
is there any way to disable checks and triggers on
a table temporarily while loading data (is updating
reltriggers in pg_class safe?)
You can take a look at pg_re
On Thursday 15 April 2004 17:19, Rajesh Kumar Mallah wrote:
> Bill Moran wrote:
> > Rajesh Kumar Mallah wrote:
> >> Hi,
> >>
> >> The problem was solved by reloading the Table.
> >> the query now takes only 3 seconds. But that is
> >> not a solution.
> >
> > If dropping/recreating the table improve
Bill Moran wrote:
Rajesh Kumar Mallah wrote:
Hi,
The problem was solved by reloading the Table.
the query now takes only 3 seconds. But that is
not a solution.
If dropping/recreating the table improves things, then we can reasonably
assume that the table is pretty active with updates/inserts.
Rajesh Kumar Mallah wrote:
Hi,
The problem was solved by reloading the Table.
the query now takes only 3 seconds. But that is
not a solution.
If dropping/recreating the table improves things, then we can reasonably
assume that the table is pretty active with updates/inserts. Correct?
The problem
Hi ,
I am not sure, but I remember the same problem.
It was ot 7.3.x version and and I needet to reindex the table.
I think after 7.4 vacuum also work correct with reindex.
But I am not sure.
regards,
ivan.
Rajesh Kumar Mallah wrote:
> Hi,
>
> The problem was solved by reloading the Table.
> t
Hi,
The problem was solved by reloading the Table.
the query now takes only 3 seconds. But that is
not a solution.
The problem is that such phenomenon obscures our
judgement used in optimising queries and database.
If a query runs slow we really cant tell if its a problem
with query itself , har
12 matches
Mail list logo
