From: | Steve Atkins <steve(at)blighty(dot)com> |
---|---|
To: | pgsql general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: queueing via database table? |
Date: | 2007-01-03 07:00:06 |
Message-ID: | AD0E0B23-6AD2-4AE5-BC4D-CB4EB4B1969B@blighty.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Jan 2, 2007, at 10:34 PM, Mark Harrison wrote:
> I have a cluster of CPUs generating thumbnails for
> a render farm. I would like to place thumbnail
> requests on a queue, and have the cluster of client
> dequeue the requests and process them.
>
> Of course, each request should be only dequeued once...
> if a thumbnail is being processed by one CPU, it
> shouldn't be processed by another CPU.
>
> Does the following sound like a reasonable approach?
> If not, what's a good way to go?
>
> The processes generating the requests will insert into
> a queue table. They may add a priority and timestamp.
>
> The several processes servicing the requests will do a
> SELECT FOR UPDATE where ... limit 1, generate thumbnail,
> delete the record and commit.
>
> Comments and suggestions welcome,
Holding a lock while generating the thumbnail doesn't
sound like a great idea, and I think that the select
for update will end up serialising the requests.
I'd add a "rendering" field, text, defaulting
to an empty string.
Then do a "select for update where ... and rendering = '' limit 1",
update the rendering field to the hostname of the box doing the
work and commit. Render the thumbnail. Delete the record.
That'll also give you an easy way to show status of which
box is rendering which scene.
Depending on what else you're putting into the where clause
a partial index on something for records where rendering=''
might be helpful.
Cheers,
Steve
From | Date | Subject | |
---|---|---|---|
Next Message | novnov | 2007-01-03 08:13:57 | Re: Generic timestamp function for updates where field |
Previous Message | Mark Harrison | 2007-01-03 06:34:24 | queueing via database table? |