On Thu, 2003-01-16 at 08:20, Andrew Sullivan wrote:
> On Thu, Jan 16, 2003 at 05:51:40AM -0800, CaptainX0r wrote:
> > All,
> >
> > I just noted in another thread that use of foreign keys in postgres
> > significantly hinders performance. I'm wondering what other
>
> Since I think I'm the one responsible for this, I'd better say
> something clearer for the record.
>
> The foreign keys implementation in PostgreSQL essentially uses SELECT
> . . . FOR UPDATE to ensure that referenced data doesn't go away while a
> referencing datum is being inserted or altered.
>
> The problem with this is that frequently-referenced data are
> therefore effectively locked during the operation. Other writers
> will block on the locked data until the first writer finishes.
>
> So, for instance, consider two artificial-example tables:
>
> create table account (acct_id serial primary key);
>
> create table acct_activity (acct_id int references
> account(acct_id), trans_on timestamp, val numeric(12,2));
>
> If a user has multiple connections and charges things to the same
> account in more than one connection at the same time, the
> transactions will have to be processed, effectively, in series: each
> one will have to wait for another to commit in order to complete.
This is true even though the default transaction mode is
READ COMMITTED?
--
+------------------------------------------------------------+
| Ron Johnson, Jr. mailto:ron.l.johnson@cox.net |
| Jefferson, LA USA http://members.cox.net/ron.l.johnson |
| |
| "Basically, I got on the plane with a bomb. Basically, I |
| tried to ignite it. Basically, yeah, I intended to damage |
| the plane." |
| RICHARD REID, who tried to blow up American Airlines |
| Flight 63 |
+------------------------------------------------------------+