From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Edmund Dengler <edmundd(at)eSentire(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Slow deletes |
Date: | 2002-08-13 13:05:12 |
Message-ID: | 24836.1029243912@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Edmund Dengler <edmundd(at)eSentire(dot)com> writes:
> Aha, I did have a dependency I missed. I did a pull from a dump:
> CREATE CONSTRAINT TRIGGER "<unnamed>" AFTER DELETE ON "syslog_event"
> FROM "syslog_event_message_event" NOT DEFERRABLE INITIALLY IMMEDIATE
> FOR EACH ROW EXECUTE PROCEDURE
> "RI_FKey_cascade_del" ('<unnamed>', 'syslog_event_message_event',
> 'syslog_event', 'UNSPECIFIED', 'event_id', 'event_id');
> Both columns are the same type (int8).
> => \d syslog_event_message_event
> Table "syslog_event_message_event"
> Column | Type | Modifiers
> ------------+--------+-----------
> message_id | bigint | not null
> event_id | bigint | not null
> Primary key: syslog_event_message_event_pkey
> Triggers: RI_ConstraintTrigger_13220957
> The table contains no rows (previously deleted, vacuumed, and analyzed).
I can't tell from this which column is the primary key? (Fortunately
someone improved the \d output so that that will be apparent in 7.3...)
Generally you want to be sure that indexes are available on both the
referenced and referencing columns of a foreign-key relationship...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2002-08-13 13:15:19 | Re: [HACKERS] Linux Largefile Support In Postgresql RPMS |
Previous Message | Larry Rosenman | 2002-08-13 13:02:05 | Re: [HACKERS] Linux Largefile Support In Postgresql RPMS |