Re: schema/db design wrt performance

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                                 |
+------------------------------------------------------------+