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

Поиск
Список
Период
Сортировка
От Stephan Szabo
Тема Re: Performance problem on delete from for 10k rows. May
Дата
Msg-id 20050316092030.S57120@megazone.bigpanda.com
обсуждение исходный текст
Ответ на Re: Performance problem on delete from for 10k rows. May  (David Gagnon <dgagnon@siunik.com>)
Список 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.

В списке pgsql-performance по дате отправления:

Предыдущее
От: "Rodrigo Moreno"
Дата:
Сообщение: Help to find out problem with joined tables
Следующее
От: Tom Lane
Дата:
Сообщение: Re: cpu_tuple_cost