Re: Performance problem on delete from for 10k rows. May - Mailing list pgsql-performance

From Dave Cramer
Subject Re: Performance problem on delete from for 10k rows. May
Date
Msg-id 42383D60.7080900@fastcrypt.com
Whole thread Raw
In response to Re: Performance problem on delete from for 10k rows. May  (David Gagnon <dgagnon@siunik.com>)
Responses Re: Performance problem on delete from for 10k rows. May
List pgsql-performance

David Gagnon wrote:

> Hi All,
>
> 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.  But if I want to
> delete the content of the table (~10k) it may be long to those 6
> selects for each deleted rows.  Why are those selects are there ?  Are
> those select really run on each row deleted?

You are using hibernate. Hibernate is generating them to lock the tables.

>
>
> I'm running version 7.4.5 on cygwin.  I ran the same delete from
> pgAdminIII and I got 945562ms for all the deletes within the same
> transaction  .. (so I was wrong saying it took less time in
> PgAdminIII... sorry about this).
>
> Do you have any idea why those 6 selects are there?

Hibernate

>
> Maybe I can drop indexes before deleting the content of the table.  I
> didn't planned to because tables are quite small and it's more
> complicated in my environment.  And tell me if I'm wrong but if I drop
> indexed do I have to reload all my stored procedure (to reset the
> planner related info)??? Remember having read that somewhere.. (was it
> in the Postgresql General Bit newletter ...anyway)
>
> Thanks for your help I really appréciate it :-)
>
> /David
>
> LOG:  duration: 144.000 ms
> LOG:  statement: DELETE FROM YN
> LOG:  duration: 30.000 ms
> LOG:  statement: DELETE FROM YO
> LOG:  statement: SELECT 1 FROM ONLY "public"."yo" x WHERE "yotype" =
> $1 AND "yonum" = $2 FOR UPDATE OF x
> LOG:  statement: SELECT 1 FROM ONLY "public"."yn" x WHERE "ynyotype" =
> $1 AND "ynyonum" = $2 FOR UPDATE OF x
> LOG:  statement: SELECT 1 FROM ONLY "public"."yo" x WHERE "yotype" =
> $1 AND "yonum" = $2 FOR UPDATE OF x
> LOG:  statement: SELECT 1 FROM ONLY "public"."yr" x WHERE "yryotype" =
> $1 AND "yryonum" = $2 FOR UPDATE OF x
> LOG:  duration: 83.000 ms
> LOG:  connection received: host=127.0.0.1 port=2196
> LOG:  connection authorized: user=admin database=webCatalog
> LOG:  statement: set datestyle to 'ISO'; select version(), case when
> pg_encoding_to_char(1) = 'SQL_ASCII' then 'UNKNOWN' else
> getdatabaseencoding() end;
> LOG:  duration: 2.000 ms
> LOG:  statement: set client_encoding = 'UNICODE'
> LOG:  duration: 0.000 ms
> LOG:  statement: DELETE FROM IY
> LOG:  duration: 71.000 ms
> LOG:  statement: DELETE FROM IA
> LOG:  duration: 17.000 ms
> LOG:  statement: DELETE FROM IQ
> LOG:  duration: 384.000 ms
> LOG:  statement: DELETE FROM IC
> LOG:  statement: SELECT 1 FROM ONLY "public"."ic" x WHERE "icnum" = $1
> FOR UPDATE OF x
> LOG:  statement: SELECT 1 FROM ONLY "public"."iq" x WHERE "iqicnum" =
> $1 FOR UPDATE OF x
> LOG:  statement: SELECT 1 FROM ONLY "public"."ic" x WHERE "icnum" = $1
> FOR UPDATE OF x
> LOG:  statement: SELECT 1 FROM ONLY "public"."ia" x WHERE "iaicnum" =
> $1 FOR UPDATE OF x
> LOG:  statement: SELECT 1 FROM ONLY "public"."ic" x WHERE "icnum" = $1
> FOR UPDATE OF x
> LOG:  statement: SELECT 1 FROM ONLY "public"."iy" x WHERE "iyicnumo" =
> $1 FOR UPDATE OF x
> LOG:  statement: SELECT 1 FROM ONLY "public"."ic" x WHERE "icnum" = $1
> FOR UPDATE OF x
> LOG:  statement: SELECT 1 FROM ONLY "public"."iy" x WHERE "iyicnumr" =
> $1 FOR UPDATE OF x
> LOG:  statement: SELECT 1 FROM ONLY "public"."ic" x WHERE "icnum" = $1
> FOR UPDATE OF x
> LOG:  statement: SELECT 1 FROM ONLY "public"."il" x WHERE "ilicnum" =
> $1 FOR UPDATE OF x
> LOG:  statement: SELECT 1 FROM ONLY "public"."ic" x WHERE "icnum" = $1
> FOR UPDATE OF x
> LOG:  statement: SELECT 1 FROM ONLY "public"."bd" x WHERE "bdicnum" =
> $1 FOR UPDATE OF x
> LOG:  duration: 656807.000 msMichael Fuhr wrote:
>
>
>
>
>
> -----------------------
> DELETE FROM BM;
> DELETE FROM BD;
> DELETE FROM BO;
> DELETE FROM IL;
> DELETE FROM YR;
> DELETE FROM YN;
> DELETE FROM YO;
> DELETE FROM IY;
> DELETE FROM IA;
> DELETE FROM IQ;
> DELETE FROM IC;
>
> Michael Fuhr wrote:
>
>> On Tue, Mar 15, 2005 at 04:24:17PM -0500, David Gagnon wrote:
>>
>>
>>
>>> Il get this strange problem when deleting rows from a Java program.
>>> Sometime (For what I noticed it's not all the time) the server take
>>> almost forever to delete rows from table.
>>>
>>
>>
>> Do other tables have foreign key references to the table you're
>> deleting from?  If so, are there indexes on the foreign key columns?
>>
>> Do you have triggers or rules on the table?
>>
>> Have you queried pg_locks during the long-lasting deletes to see
>> if the deleting transaction is waiting for a lock on something?
>>
>>
>>
>>> I rememeber having tried to delete the content of my table (IC) from
>>> PgAdminIII and I took couples of seconds!!! Not minutes.
>>>
>>
>>
>> How many records did you delete in this case?  If there are foreign
>> key references, how many records were in the referencing tables?
>> How repeatable is the disparity in delete time?  A single test case
>> might have been done under different conditions, so it might not
>> mean much.  No offense intended, but "I remember" doesn't carry as
>> much weight as a documented example.
>>
>>
>>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>
>

--
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561


pgsql-performance by date:

Previous
From: David Gagnon
Date:
Subject: Re: Performance problem on delete from for 10k rows. May
Next
From: David Gagnon
Date:
Subject: Re: Performance problem on delete from for 10k rows. May