For what it's worth, this week's run covered even more months than
last week's did, and ran in about 5 1/2 hours, with no slowdowns,
under a similar system load. So, it could have been a one-time thing
or some combination of factors that will be difficult to reproduce.
--
Mike Nolan
--
Sent
On Sun, Jan 11, 2015 at 8:07 AM, Michael Nolan htf...@gmail.com wrote:
On Sat, Jan 10, 2015 at 8:54 PM, Melvin Davidson melvin6...@gmail.com
wrote:
Just curious. Have you checked that the tables are being vacuum/analyzed
periodically and that the statistics are up to date? Try running the
OK, you might also want to look at the current values of shared_buffers,
temp_buffers work_mem in postgresql.conf.
If they seem correct/appropritate for your total shmmax memory
(kernel.shmmax parameter), then if the slowdown occurs again, monitor top
and see if it's really PostgreSQL that is
On Sat, Jan 10, 2015 at 8:54 PM, Melvin Davidson melvin6...@gmail.com
wrote:
Just curious. Have you checked that the tables are being vacuum/analyzed
periodically and that the statistics are up to date? Try running the
following query to verify:
A vacuum analyze runs every night and there
On 01/09/2015 07:52 PM, Tomas Vondra wrote:
On 9.1.2015 23:14, Michael Nolan wrote:
I'm running 9.3.5 on a virtual machine with 5 cores and 24 GB of
memory. Disk is on a SAN.
I have a task that runs weekly that processes possibly as many as
120 months worth of data, one month at a time. Since
On Fri, Jan 9, 2015 at 7:52 PM, Tomas Vondra tomas.von...@2ndquadrant.com
wrote:
On 9.1.2015 23:14, Michael Nolan wrote:
I'm running 9.3.5 on a virtual machine with 5 cores and 24 GB of
memory. Disk is on a SAN.
I have a task that runs weekly that processes possibly as many as
120
The function is a complicated plpgsql function that makes numerous database
queries, all read-only. (Other parts of that program may make changes to
the database.)
The first database shutdown and the shutdown/reboot later on were both
'clean' shutdowns, so there shouldn't have been any kind of
Just curious. Have you checked that the tables are being vacuum/analyzed
periodically and that the statistics are up to date? Try running the
following query to verify:
SELECT n.nspname,
s.relname,
c.reltuples::bigint,
-- n_live_tup,
n_tup_ins,
n_tup_upd,
On 9.1.2015 23:14, Michael Nolan wrote:
I'm running 9.3.5 on a virtual machine with 5 cores and 24 GB of
memory. Disk is on a SAN.
I have a task that runs weekly that processes possibly as many as
120 months worth of data, one month at a time. Since moving to 9.3.5
(from 8.2!!) the
I'm running 9.3.5 on a virtual machine with 5 cores and 24 GB of
memory. Disk is on a SAN.
I have a task that runs weekly that processes possibly as many as 120
months worth of data, one month at a time. Since moving to 9.3.5
(from 8.2!!) the average time for a month has been 3 minutes or less.
10 matches
Mail list logo
