Added indices on the two tables that used foreign keys to the delting
table, and voila - delete finishes fast.
Thanks for the tip, also using explain analyze, as someone else
pointed out, would have shown me, where the problem comes from.
Thanks everybody for helping.
Gerhard
--
Sent via pgsql-
On Dec 18, 2:46 pm, gerhard wrote:
> oops, should have thought about setting the foreign key constraint
> deferrable, maybe showing this in table definition (\d) would be a
> good idea.
> will recreate my foreign key deferrable and do some timings ...
OK, recreated my foreign key constraints defe
On Thu, Dec 18, 2008 at 05:29:52AM -0800, gerhard wrote:
> I'm running a delete command on a postgresql-8.1.9 server. 25000
> tuples are delete, time is ~ 400 secs
> detailid | integer | not null default nextval
> ('downtime_detail_detailid_seq'::regclass)
> downtimeid | integer |
> detail
On Thu, 2008-12-18 at 05:29 -0800, gerhard wrote:
> I suspect the foreign key constraint of downtime_detail to slow down
> the delete process. Is this a bug, probably fixed in latest version
> (8.1.x) or should I drop the constraint and recreate after deletion -
> which I only see as workaround ?
gerhard writes:
> oops, should have thought about setting the foreign key constraint
> deferrable, maybe showing this in table definition (\d) would be a
> good idea.
Don't think that'll make any difference. What *should* help is having
an index on downtime_detail.downtimeid. As-is it's got to
oops, should have thought about setting the foreign key constraint
deferrable, maybe showing this in table definition (\d) would be a
good idea.
will recreate my foreign key deferrable and do some timings ...
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to
I'm running a delete command on a postgresql-8.1.9 server. 25000
tuples are delete, time is ~ 400 secs
the command:
delete from downtime where start<'Aug 1 00:00:00 2008'
The table definitions are:
linie4=> \d downtime
Table "public.downtime"
Column
