Re: Utilizing multiple cores in a function call.

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: "Hartman, Matthew" <Matthew(dot)Hartman(at)krcc(dot)on(dot)ca>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Utilizing multiple cores in a function call.
Date: 2009-06-29 21:21:32
Message-ID: b42b73150906291421y26dd698dl1e62975e4f8c4763@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Mon, Jun 29, 2009 at 10:26 AM, Hartman,
Matthew<Matthew(dot)Hartman(at)krcc(dot)on(dot)ca> wrote:
> Good morning.
>
>
>
> I have developed a function call that schedules patient appointments within
> a day based on several resource constraints. The algorithm has been
> mentioned on here before and I have managed to tweak it down to 6-9 seconds
> from the original 27 seconds.
>
>
>
> Of course, I want it to be faster still. The function throttles one of my
> CPUs to 100% (shown as 50% in Task Manager) and leaves the other one sitting
> pretty. Is there any way to use both CPUs?

Your best bet at using multiple cores on a cpu bound problem is to try
and divide up the work logically into separate pools and to attack the
work with multiple function calls. This is probably what the database
would do for you if it had 'in-query multi threading', only the
database could attack it on a much finer grained level.

In your particular case, I think the answer is to attack the problem
in an entirely new direction, although your matrix query is one of the
coolest queries i've seen in a while.

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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Mike Ivanov 2009-06-29 23:26:30 Re: random slow query
Previous Message Greg Smith 2009-06-29 18:42:18 Re: Utilizing multiple cores in a function call.