Re: slow deletes on pgsql 7.4
| От | Junaili Lie |
|---|---|
| Тема | Re: slow deletes on pgsql 7.4 |
| Дата | |
| Msg-id | 8d04ce990604251714g1f5d99bbn172ec554a49c8374@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: slow deletes on pgsql 7.4 (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: slow deletes on pgsql 7.4
|
| Список | pgsql-performance |
hi,
Thanks for the answer.
I have double checked that all the foreign key that are referencing "id" on scenario are indexed.
I have even vacuum analyze scenario table and all the tables that referenced this table.
Something that is interesting is that: it only happens for a certain values.
ie. delete from scenario where id='1023' is very fast, but delete from scenario where id='1099' is running forever.
Any ideas?
J
Thanks for the answer.
I have double checked that all the foreign key that are referencing "id" on scenario are indexed.
I have even vacuum analyze scenario table and all the tables that referenced this table.
Something that is interesting is that: it only happens for a certain values.
ie. delete from scenario where id='1023' is very fast, but delete from scenario where id='1099' is running forever.
Any ideas?
J
On 4/25/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Junaili Lie" <junaili@gmail.com> writes:
> we encounter issues when deleting from a table based on id (primary key). O=
> n
> certain 'id', it took forever to delete and the i/o is 100% busy.
Almost always, if delete is slow when selecting the same rows is fast,
it's because you've got a trigger performance problem --- most commonly,
there are foreign keys referencing this table from other tables and you
don't have the referencing columns indexed.
regards, tom lane
В списке pgsql-performance по дате отправления: