Aaron Werman [EMAIL PROTECTED] writes:
I imagine a design where a shared plan cache would consist of the plans,
indexed by a statement hash and again by dependant objects. A statement to
be planned would be hashed and matched to the cache. DDL would need to
synchronously destroy all dependant
Help?
Normally, this query takes from 5 minutes to 2 hours to run. On this update, it's
been running for more than 10 hours.
Can it be helped?
UPDATE obs_v
SET mag = obs_v.imag + zp.zero_v + cg.color_v * (obs_v.imag - i.imag),
use = true
FROM color_groups AS cg, zero_pair AS zp, obs_i AS
What does observations_trigger do?
On Tue, 28 Sep 2004 08:19:57 -0600, Robert Creager
[EMAIL PROTECTED] wrote:
Help?
Normally, this query takes from 5 minutes to 2 hours to run. On this update, it's
been running for more than 10 hours.
Can it be helped?
UPDATE obs_v
SET mag =
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
To: Aaron Werman [EMAIL PROTECTED]
Cc: Iain [EMAIL PROTECTED]; Jim C. Nasby [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Tuesday, September 28, 2004 9:58 AM
Subject: Re: [PERFORM] Caching of Queries
Aaron Werman [EMAIL PROTECTED]
Robert Creager [EMAIL PROTECTED] writes:
Normally, this query takes from 5 minutes to 2 hours to run. On this update, it's
been running for more than 10 hours.
...
- Nested Loop (cost=250.69..129094.19 rows=77211 width=59)
- Hash Join (cost=250.69..307.34 rows=67
Robert Creager wrote:
Help?
Normally, this query takes from 5 minutes to 2 hours to run. On this update, it's
been running for more than 10 hours.
Can it be helped?
When I see this usually means that tables are full of
dead rows. Did you vacuum you DB. Which version are you
using ?
Regards
Folks,
I'm beginning a series of tests on OSDL's Scalable Test Platform in order to
determine some recommended settings for many of the new PostgreSQL.conf
parameters as well as pg_autovacuum.
Is anyone else interested in helping me with this?
--
--Josh
Josh Berkus
Aglio Database
I could spend a week or two tweaking the performance of my database servers
and probably make some sizeable improvements, but I'm not going to.
Why? Because PostgreSQL screams as it is.
I would make sure that if the consensus is to add some sort of caching that
it be done only if there is no hit
When grilled further on (Tue, 28 Sep 2004 09:28:47 -0500),
Kevin Barnard [EMAIL PROTECTED] confessed:
What does observations_trigger do?
The trigger keeps another table (catalog) up to date with the information from the
obs_v and obs_i tables. There are no direct insert/update/delete's on
When grilled further on (Tue, 28 Sep 2004 16:55:13 +0200),
Gaetano Mendola [EMAIL PROTECTED] confessed:
Robert Creager wrote:
Help?
Normally, this query takes from 5 minutes to 2 hours to run. On this
update, it's been running for more than 10 hours.
Can it be helped?
When I
On Tue, 28 Sep 2004 20:21:40 -0600, Robert Creager
[EMAIL PROTECTED] wrote:
The trigger keeps another table (catalog) up to date with the information from the
obs_v and obs_i tables. There are no direct insert/update/delete's on the catalog
table, only though the trigger.
It's possible
When grilled further on (Tue, 28 Sep 2004 21:41:50 -0500),
Kevin Barnard [EMAIL PROTECTED] confessed:
On Tue, 28 Sep 2004 20:21:40 -0600, Robert Creager
[EMAIL PROTECTED] wrote:
The trigger keeps another table (catalog) up to date with the information
from the obs_v and obs_i tables.
When grilled further on (Tue, 28 Sep 2004 11:04:23 -0400),
Tom Lane [EMAIL PROTECTED] confessed:
Robert Creager [EMAIL PROTECTED] writes:
Normally, this query takes from 5 minutes to 2 hours to run. On this
update, it's been running for more than 10 hours.
...
- Nested Loop
13 matches
Mail list logo
