On Wed, 16 Mar 2005, David Gagnon wrote:
> Hi
>
> >>I rerun the example with the debug info turned on in postgresl. As you
> >>can see all dependent tables (that as foreign key on table IC) are
> >>emptied before the DELETE FROM IC statement is issued. For what I
> >>understand the performance problem seem to came from those selects that
> >>point back to IC ( LOG: statement: SELECT 1 FROM ONLY "public"."ic" x
> >>WHERE "icnum" = $1 FOR UPDATE OF x). There are 6 of them. I don't know
> >>where they are comming from.
> >>
> >>
> >
> >I think they come from the FK checking code. Try to run a VACUUM on the
> >IC table just before you delete from the other tables; that should make
> >the checking almost instantaneous (assuming the vacuuming actually
> >empties the table, which would depend on other transactions).
> >
> >
> I'll try to vaccum first before I start the delete to see if it change
> something.
>
> There is probably a good reason why but I don't understant why in a
> foreign key check it need to check the date it points to.
>
> You delete a row from table IC and do a check for integrity on tables
> that have foreign keys on IC (make sense). But why checking back IC?
Because in the general case there might be another row which satisfies the
constraint added between the delete and the check.
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
