On 5/1/07, Alban Hertroys <alban@xxxxxxxxxxxxxxxxx> 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
