| From: | Patric de Waha <lists(at)p-dw(dot)com> |
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Delete Cascade FK speed issue |
| Date: | 2007-07-03 06:05:27 |
| Message-ID: | 4689E727.5020408@p-dw.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Hi,
I've dbase with about 80 relations.
On deleting a user, this cascades through all the tables.
This is very slow, for 20 users it takes 4 hours, with exclusive
access to the dbase.
No other users connected to the dbase.
Ok I know there will be somewhere a relation with a FK without
index, which
is being scanned sequentially. But how can I find out what postgres
is doing
while it is handling the transaction?
Is there a way I can find out what postgres does, and where it hangs
around, so I know
where the FK might not be indexed. (The dbase is to big to analyze
it by hand).
The way I do it now is to check the pg_locks relation, but this is
not very representative.
Is there profiling method for triggers/constraints, or a method
which gives me a hint
why it is taking so long?
thanks in advance
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Fuhr | 2007-07-03 11:33:42 | Re: Delete Cascade FK speed issue |
| Previous Message | Gregory Stark | 2007-07-03 00:04:46 | Re: Join with lower/upper limits doesn't scale well |