On 5/1/07, Alban Hertroys <alban@magproductions.nl> wrote:
> Whether that improves your performance pretty much depends on the queue
> sizes, the frequency of processing and the load processing causes...
> Heh, I just realize we have a work queue table here as well, I'd like to
> know the result.
the optimization here is that we are not updating job.status to flag
which jobs are done or not. this is extremely high concurrency
solution but the advantage is moot if the jobs not extremely short.
you can insert into a completed jobs table but you don't have to check
that to get the next undone job. it might be impractical to do it
this way for real jobs...
thinking about it some more, the only way to skip a job would if the
race condition happened at or near the end of the queue.
> > generating unique number if used with nextval(), setval(), etc. but
> > not necessarily
> > select last_value from s;
> >
> > from point of view of comparing that value with something else and
> > incrementing it if and only if that condition is true in a consistent
> > context.
>
> Indeed, that's one of the weaknesses of last_val. With your example I
> now understand why it even exists, I always thought it an odd and
> dangerous feature.
small clarification here...i'm not acually looking at the lastval
function (get the last returned value by sequence in this session) but
the 'last_value' column of the sequences (get the last value returned
to any session for this sequence. a cooperative lock is the only way
to prevent other sessions from jerking the sequence around via the
'non-mvcc' sequence functions.
merlin