I have tried to wrap my brain around different approaches but I'm still stuck with this one so far. Your approach is interesting but the problem is more complicated than that. Let me break it down a bit more. The chemotherapy treatment room is divided into groupings of chairs, called pods. Pod 1 could have three chairs, pod 2 could have two, and so forth. Every day can have a unique number of pods, chairs, and groupings of chairs to pods. Furthermore, every day can have a unique number of nurses, and nurses are assigned to one or more pods. A single nurse could be assigned to cover three pods for example. On top of that, pods have a start/end time as well as nurses. Every pod and nurse can have unique start/end times. Chemotherapy regimens have a required chair time and a required nurse time. The required nurse time represents how long it takes a nurse to start the treatment. To schedule an appointment, both the chair and nurse have to be available for the required times at the same time, while also respecting the pod/chair and pod/nurse assignments. It's more than incrementing/decrementing the total available time. Thanks, Matthew Hartman Programmer/Analyst Information Management, ICP Kingston General Hospital (613) 549-6666 x4294 -----Original Message----- From: Merlin Moncure [mailto:mmoncure@xxxxxxxxx] Sent: Monday, June 29, 2009 5:22 PM To: Hartman, Matthew Cc: pgsql-performance@xxxxxxxxxxxxxx Subject: Re: Utilizing multiple cores in a function call. The first thought that jumped out at me was to try and treat your nurses and stations as incrementing numbers so that if you allocate three hours of nurse x's time, you increment some number by three in the nurse's table. This would lay on top of a kind of a time calculation system that would convert that number to actual time based on the nurses schedule, etc. On top of _that_, you would need some kind of resolution system to handle canceled appointments, nurse no-shows, etc. The stations would operate on a similar principle...you imagine all the available hours for the station stretched to infinity on a number line and keep a fixed allocation point which always moves forwards, plus a 'number line time' -> real time converter and a freestore list to pick up unexpectedly freed time. merlin -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance