On Mon, 2009-06-29 at 14:42 -0400, Greg Smith wrote:
> -Write a "worker server" that you prompt to pick up work from a table and
> write its output to another that you can ask to handle part of the job.
> You might communicate with the worker using the LISTEN/NOTIFY mechanism in
> the database.
Hi Sean,
Sean Ma wrote:
One months ago, this type of slow query happened about a few time per
day. But recently, the slow query happens more frequent at the rate of
once every 10 minutes or less. There seesm not relation to th
What is your hardware (memory, CPU type and such)?
This seems like
On Mon, Jun 29, 2009 at 10:26 AM, Hartman,
Matthew 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 s
On Mon, 29 Jun 2009, Hartman, Matthew wrote:
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?
Not easily. Potential techniques:
-Rewrite the function or its time critical portion in some
Hartman, Matthew wrote:
I'm pretty much at that point where I've chewed the fat off of the
algorithm, or at least at my personal limits. Occasionally a new idea
pops into my head and yields an improvement but it's in the order of
100-250ms.
Google came back with "no sir". It seems PostgreSQL is
I'm pretty much at that point where I've chewed the fat off of the
algorithm, or at least at my personal limits. Occasionally a new idea
pops into my head and yields an improvement but it's in the order of
100-250ms.
Google came back with "no sir". It seems PostgreSQL is limited to one
CPU per que
Sean Ma wrote:
> I have a table about 50 million rows. There are a few writers to
> pump data into the table at the rate of 4 row/hours. Most the
> time, the SELECT is less than 100 ms. However sometime it is very
> slow, from 30 seconds to 500 seconds. The database is vacuum analyze
> regula
Hartman, Matthew 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.
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
On 06/29/2009 03:33 PM, Sean Ma wrote:
I have a table about 50 million rows. There are a few writers to pump
data into the table at the rate of 4 row/hours. Most the time, the
SELECT is less than 100 ms. However sometime it is very slow, from 30
seconds to 500 seconds. The database is vacuum
I have a table about 50 million rows. There are a few writers to pump
data into the table at the rate of 4 row/hours. Most the time, the
SELECT is less than 100 ms. However sometime it is very slow, from 30
seconds to 500 seconds. The database is vacuum analyze regularly.
One months ago, this
>
> You're right that it should be removed, but this explanation is wrong. The
> behavior as configured is actually "if there are >=100 other transactions in
> progress, wait 0.1 second before committing after the first one gets
> committed", in hopes that one of the other 100 might also join along
12 matches
Mail list logo
