From: | Atesz <atesz(at)ritek(dot)hu> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: ACCESS EXCLUSIVE lock |
Date: | 2006-10-19 13:44:10 |
Message-ID: | 4537812A.3060408@ritek.hu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Scott Marlowe wrote:
> What if, a minute or two after the drop contraint, you issue a rollback?
>
After the DROP CONSTRAINT I insert 4 million rekords into the TABLE b.
After the inserts I remake the dropped constraints, and commit the
transaction (P1). This solution is faster then the conventional method
without the constraint's trick.
In my work the table A is a dictionary table (key-value pairs) with
100-200 records, and the TABLE b has 20 columns with 10 references to
TABLE a. So my experience is that I have to drop constraints before the
4 million inserts and remake those after it.
If there is an error in my transaction (P1) and I have to rollback,
there isn't problem, because my inserts lost from TABLE b and the
dropped constraints may be rolled back. In my opinion there isn't
exclusion between a dropped constraint (reference from b to a) and a
select on TABLE a. If I think well the dropped constraint have to seem
in other transation (for example: P2). And it doesn't have to seem in my
transaction, because it has already dropped.
Thanks your suggestions!
Regards,
Antal Attila
From | Date | Subject | |
---|---|---|---|
Next Message | Tobias Brox | 2006-10-19 13:54:28 | Swappiness setting on a linux pg server |
Previous Message | Andrzej Zawadzki | 2006-10-19 13:30:35 | VACUUM FULL ANALYZE on 8.1.4 is slower then on 8.0 |