Hi,
I have found the bug in my code that made the update to the same row in the
table instead of two different row. Now I have all cores up and running
100%.
Thank you for all your help.
On Fri, Mar 18, 2011 at 3:21 PM, Kevin Grittner kevin.gritt...@wicourts.gov
wrote:
Red Maple
Hi all,
Our system has a postgres database that has a table for statistic which is
updated every hour by about 10K clients. Each client only make update to its
own row in the table. So far I am only seeing one core out of eight cores on
my server being active which tells me that the update is
Red Maple redmaplel...@gmail.com wrote:
Our system has a postgres database that has a table for statistic
which is updated every hour by about 10K clients. Each client only
make update to its own row in the table. So far I am only seeing
one core out of eight cores on my server being active
From: pgsql-performance-ow...@postgresql.org
[mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Red Maple
Sent: Friday, March 18, 2011 9:05 AM
To: pgsql-performance@postgresql.org
Subject: [PERFORM] Help: massive parallel update to the same table
Hi all,
Our system has a postgres
[rearranged - please don't top-post]
[also, bringing this back to the list - please keep the list copied]
Red Maple redmaplel...@gmail.com wrote:
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
It should be parallel by default. Are you taking out any
explicit locks?
my clients use
Hi,
Here is my function. If I comment out the update then it would run all the
cores, if not then only one core will run
CREATE OR REPLACE FUNCTION my_update_device(this_mac text, number_of_devices
integer, this_sysuptime integer)
RETURNS integer AS
$BODY$
DECLARE
fake_mac
Red Maple redmaplel...@gmail.com wrote:
Here is my function. If I comment out the update then it would run
all the cores, if not then only one core will run
CREATE OR REPLACE FUNCTION
[...]
select sysuptime
into this_sysuptime
from ap_sysuptime
