Skip site navigation (1) Skip section navigation (2)

constraint with reference to the same table

From: "Victor Yegorov" <viy(at)nordlb(dot)lv>
To: "Postgres Performance" <pgsql-performance(at)postgresql(dot)org>
Subject: constraint with reference to the same table
Date: 2003-05-14 23:11:33
Message-ID: 20030514231133.GB1549@nordlb.lv (view raw or flat)
Thread:
Lists: pgsql-performance
Hello.

I'm using PostgreSQL 7.3.1 on i686-pc-linux-gnu, compiled by GCC egcs-2.91.66.

Here is topic. Table transactions:

=> \d transactions
      Table "public.transactions"
   Column    |     Type     | Modifiers
-------------+--------------+-----------
 trxn_id     | integer      | not null
 trxn_ret    | integer      |
 trxn_for    | integer      |
 status      | numeric(2,0) | not null
 auth_status | numeric(2,0) | not null
Indexes: transactions_pkey primary key btree (trxn_id)
Foreign Key constraints: trxns_id FOREIGN KEY (trxn_id) REFERENCES connections(conn_id) ON UPDATE NO ACTION ON DELETE NO ACTION,
                         trxns_ret FOREIGN KEY (trxn_ret) REFERENCES transactions(trxn_id) ON UPDATE NO ACTION ON DELETE NO ACTION,
                         trxns_for FOREIGN KEY (trxn_for) REFERENCES transactions(trxn_id) ON UPDATE NO ACTION ON DELETE NO ACTION

As you can see, trxns_ret and trxns_for constraints references to the same table they come from.

Maintenance of system includes the following step:
delete from transactions where transactions.trxn_id = uneeded_trxns.trxn_id;
transactions volume is about 10K-20K rows.
uneeded_trxns volume is about 3K-5K rows.


Problem: It takes to MUCH time. EXPLAIN says:
=> explain delete from transactions where transactions.trxn_id = balance_delete_data.conn_id;
                                    QUERY PLAN
-----------------------------------------------------------------------------------
 Hash Join  (cost=86.47..966.66 rows=5238 width=14)
   Hash Cond: ("outer".trxn_id = "inner".conn_id)
   ->  Seq Scan on transactions  (cost=0.00..503.76 rows=24876 width=10)
   ->  Hash  (cost=73.38..73.38 rows=5238 width=4)
         ->  Seq Scan on balance_delete_data  (cost=0.00..73.38 rows=5238 width=4)
(5 rows)

I was waiting for about 30 minutes and then hit ^C.

After some time spent dropping indexes and constraints, I've found out, that problem was in
those 2 "cyclic" constraints. After drop, query passed in some seconds (that is suitable).

Question: why so?
Thanks in advance.

-- 

Victor Yegorov

Responses

pgsql-performance by date

Next:From: Stephan SzaboDate: 2003-05-14 23:28:55
Subject: Re: constraint with reference to the same table
Previous:From: Jamie LawrenceDate: 2003-05-14 00:11:17
Subject: Re: Finding filenames for tables

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group