From: | Jean-Christian Imbeault <jc(at)mega-bucks(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Performance question |
Date: | 2003-07-02 06:27:02 |
Message-ID: | 3F027B36.5050009@mega-bucks.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane wrote:
>
> That doesn't really buy anything in safety terms: if two backends
> execute this sort of command concurrently, it's perfectly likely
> that both sub-SELECTS will find no row matching 'v1', and so they'll
> both try the INSERT anyway.
I wasn't looking for safety so much as avoiding the insert if possible.
I've just finished a long thread about this and the consensus was that
this query would be:
1- the insert would always happen if there was no record with the same
primary key
2- is concurrency safe. Even if this query is executed by multiple
backends at the same time one will always succeed.
The reason I had asked for a query that could check before insert was to
reduce the number of log errors the phpOpenTracker tool generates from
trying to insert duplicate records into a table.
The above would reduce (but not eliminate) the number attempts to insert
duplicates and as such reduce the number of log error entries.
At least that's what I am hoping for ...
Jean-Christian Imbeault
From | Date | Subject | |
---|---|---|---|
Next Message | Ross Johnson | 2003-07-02 06:47:57 | Exporting large objects in 7.0.2 |
Previous Message | Tom Lane | 2003-07-02 06:14:30 | Re: Performance question |