Re: Performance problem on delete from for 10k rows. May

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: David Gagnon <dgagnon(at)siunik(dot)com>
Cc: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, Michael Fuhr <mike(at)fuhr(dot)org>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Performance problem on delete from for 10k rows. May
Date: 2005-03-16 20:35:45
Message-ID: 20050316092030.S57120@megazone.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, 16 Mar 2005, David Gagnon wrote:

>
>
> Stephan Szabo wrote:
>
> >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.
> >
> >
> >
> So it's means if I want to reset the shema with DELETE FROM Table
> statemnets I must first drop indexes, delete the data and then recreate
> indexes and reload stored procedure.
>
> Or I can suspend the foreign key check in the db right. I saw something
> on this. Is that possible to do this from the JDBC interface?

I think you can remove the constraints and re-add them after which should
hopefully be fast (a vacuum on the tables after the delete and before the
add might help, but I'm not sure). You could potentially defer the
constraint if it were deferrable, but I don't think that would help any.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2005-03-16 20:42:18 Re: cpu_tuple_cost
Previous Message Rodrigo Moreno 2005-03-16 20:10:17 Help to find out problem with joined tables