On 10.11.2015 07:23, Craig Ringer wrote:
On 10 November 2015 at 01:38, Jeff Janes wrote:
this would be handy in conjunction with LIMIT
(which also doesn't exist for UPDATE right now).
... and, in turn, UPDATE ... ORDER BY ..., since LIMIT without ORDER
BY is usually
On 11 November 2015 at 16:02, Torsten Zühlsdorff <
mailingli...@toco-domains.de> wrote:
> From my experience most databases are just tpo small. Their operations
> finish before there can be a deadlock. Same for race conditions - most
> developer don't know about them, because they never stumbled
On Wed, Nov 11, 2015 at 6:57 PM, Gavin Flower
wrote:
> Don't you realize that 400MB is over 4 million of the old 100Kb floppy
> disks, and even with the new big 1.44MB 3.5 " disks, you'd need about 280!!!
Don't be silly. It's only four thousand 100Kb floppies.
--
On 12/11/15 13:52, Greg Stark wrote:
On Wed, Nov 11, 2015 at 6:57 PM, Gavin Flower
wrote:
Don't you realize that 400MB is over 4 million of the old 100Kb floppy
disks, and even with the new big 1.44MB 3.5 " disks, you'd need about 280!!!
Don't be silly. It's
On 12/11/15 02:07, Craig Ringer wrote:
On 11 November 2015 at 16:02, Torsten Zühlsdorff
>
wrote:
From my experience most databases are just tpo small. Their
operations finish before there can be a deadlock. Same for
HI,
My case is concurrency update one row(for exp 1000 client update the same row
at the same time), and target is prevent waiting for waiters(quick return to
client).
use advisory lock is a method, for quick return. but not good , must use
function(to reduce consume between client-db network).
On Mon, Nov 9, 2015 at 9:06 AM, Tom Lane wrote:
> =?GBK?B?tcK45w==?= writes:
>>PostgreSQL 9.5 added skip locked to select for update to improve
>> concurrency performance, but why not add it to update sql?
>
> Seems like you'd have unpredictable results
On 9 November 2015 at 17:06, Tom Lane wrote:
> =?GBK?B?tcK45w==?= writes:
> >PostgreSQL 9.5 added skip locked to select for update to improve
> concurrency performance, but why not add it to update sql?
>
> Seems like you'd have unpredictable results from
HI,
PostgreSQL 9.5 added skip locked to select for update to improve concurrency
performance, but why not add it to update sql?
this is an application case, some body will update a tuple at the same time,
so the RT for waiter is big, I use function and select for update nowait or
=?GBK?B?tcK45w==?= writes:
>PostgreSQL 9.5 added skip locked to select for update to improve
> concurrency performance, but why not add it to update sql?
Seems like you'd have unpredictable results from the update then.
regards, tom lane
--
Sent
On 10 November 2015 at 01:38, Jeff Janes wrote:
> this would be handy in conjunction with LIMIT
> (which also doesn't exist for UPDATE right now).
... and, in turn, UPDATE ... ORDER BY ..., since LIMIT without ORDER
BY is usually not a great choice.
I'd quite like to see
11 matches
Mail list logo