Hi Craig Ringer,
Really appreciate a lot for your advice! This at least has cleared my doubt,
which had been confused me for quite some time.
Thanks and Regards
Yan Cheng CHEOK
--- On Fri, 1/22/10, Craig Ringer wrote:
> From: Craig Ringer
> Subject: Re: [GENERAL] Extremely Slow C
Yan Cheng Cheok wrote:
> I try to create a following simple scenario, to demonstrate cascade delete is
> rather slow in PostgreSQL.
>
> Can anyone help me to confirm? Is this my only machine problem, or every
> PostgreSQL users problem?
>
> I create 1 lot.
> every lot is having 1 unit
> eve
other database (like
MySQL) experience same issues too?
Thanks and Regards
Yan Cheng CHEOK
--- On Wed, 1/13/10, Grzegorz Jaśkiewicz wrote:
> From: Grzegorz Jaśkiewicz
> Subject: Re: [GENERAL] Extremely Slow Cascade Delete Operation
> To: "Yan Cheng Cheok"
> Cc: pgsql-
Yan Cheng Cheok wrote:
> I simply run a delete operation :
>
> delete from lot where lot_id = 3;
>
> It takes TWO hours and never able to return!
What does:
EXPLAIN DELETE FROM lot WHERE lot_id = 3;
report?
By the way, you've created a LOT of indexes. Indexes speed up lookups,
but can slow d
ger
> Subject: Re: [GENERAL] Extremely Slow Cascade Delete Operation
> To: "Yan Cheng Cheok"
> Cc: pgsql-general@postgresql.org
> Date: Wednesday, January 13, 2010, 7:01 PM
> On 13/01/2010 4:09 PM, Yan Cheng
> Cheok wrote:
> > I have 3 tables - lot, unit and
OMG, I never know what is index (Sorry for my newbies) I will study about them
and update you all about their performance.
Thanks and Regards
Yan Cheng CHEOK
--- On Wed, 1/13/10, Craig Ringer wrote:
> From: Craig Ringer
> Subject: Re: [GENERAL] Extremely Slow Cascade Delete Operatio
On 13/01/2010 4:09 PM, Yan Cheng Cheok wrote:
I have 3 tables - lot, unit and measurement
1 lot is having relationship to many unit.
1 unit is having relationship to many measurement.
delete cascade is being used among their relationship
SemiconductorInspection=# delete from lot where lot_id
come it takes so long?
There are only 1000++ row of unit, where their lot_id is 2.
Seems not reasonable to me. :(
Thanks and Regards
Yan Cheng CHEOK
--- On Wed, 1/13/10, Grzegorz Jaśkiewicz wrote:
> From: Grzegorz Jaśkiewicz
> Subject: Re: [GENERAL] Extremely Slow Cascade Delete Operatio
It doesn't look like it is locked, so it is carrying the delete out.
However that doesn't mean, that there isn't any other locking
occurring, or simply your disks are rather busy.
Also, maybe the DB is rather big, what are the table sizes ?
If you are using 8.4+, than do \dt+ to get an idea, other
It looks like this :
http://sites.google.com/site/yanchengcheok/Home/log.txt
I put it in google site, for easy reading)
Any hint? Thanks!
Thanks and Regards
Yan Cheng CHEOK
--- On Wed, 1/13/10, Grzegorz Jaśkiewicz wrote:
> From: Grzegorz Jaśkiewicz
> Subject: Re: [GENERAL] Extremel
try checking if it is waiting perhaps for something (is locked).
Peek at: (using different connection)
SELECT * FROM pg_stat_activity;
SELECT * FROM pg_locks;
Did you used prepared transactions ?
Try:
SELECT * FROM pg_prepared_xacts ;
Maybe some other transaction is blocking it.
HTH
--
Sent
11 matches
Mail list logo
