Re: Extremely Slow Cascade Delete Operation
От | Yan Cheng Cheok |
---|---|
Тема | Re: Extremely Slow Cascade Delete Operation |
Дата | |
Msg-id | 819416.78075.qm@web65714.mail.ac4.yahoo.com обсуждение исходный текст |
Ответ на | Re: Extremely Slow Cascade Delete Operation (Grzegorz Jaśkiewicz <gryzman@gmail.com>) |
Список | pgsql-general |
SemiconductorInspection=# \dt+ List of relations Schema | Name | Type | Owner | Size | Description --------+------------------+-------+----------+------------+------------- public | lot | table | postgres | 8192 bytes | public | measurement | table | postgres | 529 MB | public | measurement_type | table | postgres | 8192 bytes | public | measurement_unit | table | postgres | 8192 bytes | public | unit | table | postgres | 57 MB | (5 rows) I can see the PostgreSQL process is occupy CPU. But how come it takes so long? There are only 1000++ row of unit, where theirlot_id is 2. Seems not reasonable to me. :( Thanks and Regards Yan Cheng CHEOK --- On Wed, 1/13/10, Grzegorz Jaśkiewicz <gryzman@gmail.com> wrote: > From: Grzegorz Jaśkiewicz <gryzman@gmail.com> > Subject: Re: [GENERAL] Extremely Slow Cascade Delete Operation > To: "Yan Cheng Cheok" <yccheok@yahoo.com> > Cc: pgsql-general@postgresql.org > Date: Wednesday, January 13, 2010, 4:35 PM > 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, > otherwise SELECT > pg_size_pretty(pg_total_relation_size('table_name')); for > each table. > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general >
В списке pgsql-general по дате отправления: