> From: Simon Riggs [mailto:si...@2ndquadrant.com]
> Sent: Tuesday, July 07, 2009 5:39 AM
>
> Another way would be to arrange all appointments that need odd number
of
> timeslots into pairs so that you have at most one appointment that
needs
> an odd number of timeslots. Then schedule appointments
On Tue, 2009-06-16 at 14:35 -0400, Hartman, Matthew wrote:
> The algorithm for packing appointments in respects each constraint and
> typically schedules a day of treatments (30-60) within 9-10 seconds on
> my workstation, down from 27 seconds initially. I would like to get it
> below 5 seconds i
-performance-ow...@postgresql.org] On Behalf Of Anthony
Presley
Sent: Tuesday, June 16, 2009 3:37 PM
To: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Speeding up a query.
On the DB side of things, you will want to make sure that your caching
as much as possible - putting a front-end like memca
Alberto Dalmaso writes:
> P.S.: i'm trying with all enable_* to on and pumping to higher values
> from_collapse_limit and join_collapse_limit that I've put to 30.
> The result is that the query, after an hour of work, goes out of memory
> (SQL State 53200)...
Hmm, is that happening during plannin
I promised to provide more details of the query (or the function as it is).
Here goes.
Scenario:
A chemotherapy regimen requires chair time and nursing time. A patient might
sit in the chair for three hours but the nurse only has to be with them for the
first hour. Therefore, nurses can ma
neral Hospital
(613) 549- x4294
-Original Message-
From: Merlin Moncure [mailto:mmonc...@gmail.com]
Sent: Wednesday, June 17, 2009 9:09 AM
To: Hartman, Matthew
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Speeding up a query.
On Tue, Jun 16, 2009 at 2:35 PM, Hartman,
Matthew
Alberto Dalmaso wrote:
> P.S.: i'm trying with all enable_* to on and pumping to higher
> values from_collapse_limit and join_collapse_limit that I've put to
> 30.
Tom suggested that you set those numbers higher than the number of
tables joined in the query. I don't think 30 will do that.
>
On Tue, Jun 16, 2009 at 2:35 PM, Hartman,
Matthew wrote:
> Good afternoon.
>
> I have developed an application to efficiently schedule chemotherapy
> patients at our hospital. The application takes into account several
> resource constraints (available chairs, available nurses, nurse coverage
> ass
yes, I have to make that because the data on the table need to be
pivoted so it is joined many times with different filter on the column
that describe the meaning of the column called numeric_value I'm going
to show.
That could be very ineffective, event because that table contains
something like 2
On Wed, Jun 17, 2009 at 8:33 AM, Albe Laurenz wrote:
>
> I don't understand your data model well enough to understand
> the query, so I can only give you general hints (which you probably
> already know):
He is effectively joining same table 4 times in a for loop, to get
result, this is veeery in
Matthew Hartman wrote:
> To determine the available slots, the algorithm finds the earliest slot
> that has an available chair and a count of the required concurrent
> intervals afterwards. So a 60 minute regimen requires 12 concurrent
> rows. This is accomplished by joining the table on itself. A
On the DB side of things, you will want to make sure that your caching
as much as possible - putting a front-end like memcached could help. I
assume you have indexes on the appropriate tables? What does the
EXPLAIN ANALYZE on that query look like?
Not necessarily a "postgres" solution, but I'd t
Good afternoon.
I have developed an application to efficiently schedule chemotherapy
patients at our hospital. The application takes into account several
resource constraints (available chairs, available nurses, nurse coverage
assignment to chairs) as well as the chair time and nursing time
requir
13 matches
Mail list logo
