When grilled further on (Wed, 11 Jan 2006 10:33:03 -0500),
Tom Lane <[EMAIL PROTECTED]> confessed:
> The planner understands about transitivity of equality, ie given a = b
> and b = c it can infer a = c. It doesn't do any such thing for
> inequalities though, nor does it deduce f(a) = f(b) for ar
When grilled further on (Wed, 11 Jan 2006 07:26:59 -0700),
Robert Creager <[EMAIL PROTECTED]> confessed:
>
> weather-# SELECT *, unmunge_time( time_group ) AS time,
> weather-# EXTRACT( doy FROM unmunge_time( time_group ) )
> weather-# FROM minute."windspeed"
> wea
When grilled further on (Wed, 11 Jan 2006 00:56:55 -0700),
Michael Fuhr <[EMAIL PROTECTED]> confessed:
> On Tue, Jan 10, 2006 at 10:10:55PM -0700, Robert Creager wrote:
> > The query is now correct, but still is slow because of lack of
> > index usage. I don't know
Ok, I'm back, and in a little better shape.
The query is now correct, but still is slow because of lack of index usage. I
don't know how to structure the query correctly to use the index.
Taken individually:
weather=# explain analyze select * from doy_agg where doy = extract( doy from
now()
When grilled further on (Mon, 9 Jan 2006 22:58:18 -0700),
Michael Fuhr <[EMAIL PROTECTED]> confessed:
> On Mon, Jan 09, 2006 at 09:23:38PM -0700, Robert Creager wrote:
> > I'm working with a query to get more info out with a join. The base
> > query works great speed w
Hey folks,
I'm working with a query to get more info out with a join. The base query
works great speed wise because of index usage. When the join is tossed in, the
index is no longer used, so the query performance tanks.
Can anyone advise on how to get the index usage back?
weather=# selec
I've now backed off to version 7.4.1, which doesn't exhibit the problems that
8.0.3 does. I guess I'll wait 'till the next version and see if any progress
has occurred.
Rob
When grilled further on (Tue, 19 Jul 2005 22:49:08 -0600),
Robert Creager <[EMAIL PROTECTED]>
When grilled further on (Tue, 19 Jul 2005 12:09:51 -0600),
Robert Creager <[EMAIL PROTECTED]> confessed:
> On Tue, 19 Jul 2005 12:54:22 -0400
> Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > Hmm, I hadn't thought about the possible impact of multiple concurrent
> &
On Tue, 19 Jul 2005 12:54:22 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Robert Creager <[EMAIL PROTECTED]> writes:
>
> Hmm, I hadn't thought about the possible impact of multiple concurrent
> vacuums. Is the problem caused by that, or has performance already gon
On Tue, 19 Jul 2005 12:54:22 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Hmm, I hadn't thought about the possible impact of multiple concurrent
> vacuums. Is the problem caused by that, or has performance already gone
> into the tank by the time the cron-driven vacuums are taking long enough
> to
On Mon, 18 Jul 2005 13:52:53 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> Start a fresh psql session and "SHOW vacuum_cost_delay" to verify what
> the active setting is.
>
Alright. Restarted the 803 database. Cron based vacuum analyze is running
every 5 minutes. vacuum_cost_delay is 0. The
ll restart
the 803 db, vacuum full analyze again and next opportunity (maybe tonight),
start runs again with cron vacuum and a vacuum_cost_delay of 0, unless I should
try something else?
Cheers,
Rob
--
Robert Creager
Advisory Software Engineer
Phone 303.673.2365
Pager 888.912.
On Mon, 18 Jul 2005 13:52:53 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Start a fresh psql session and "SHOW vacuum_cost_delay" to verify what
> the active setting is.
Thanks. It does show 0 for 803 in a session that was up since I thought I had
HUPed the server with the new value.
This is lea
When grilled further on (Mon, 18 Jul 2005 09:23:11 -0400),
Tom Lane <[EMAIL PROTECTED]> confessed:
> It's still far from clear what's going on there, but it might be
> interesting to see if turning off the vacuum delay changes your results
> with 8.0.
>
Can that be affected by hupping the server
When grilled further on (Mon, 18 Jul 2005 00:10:53 -0400),
Tom Lane <[EMAIL PROTECTED]> confessed:
> The context swap problem was no worse in 8.0 than in prior versions,
> so that hardly seems like a good explanation. Have you tried reverting
> to the cron-based vacuuming method you used in 7.4?
When grilled further on (Sun, 17 Jul 2005 23:43:29 -0600),
Robert Creager <[EMAIL PROTECTED]> confessed:
> I've 6 runs going concurrently. Just saw (vmstat 1) a set of 8 seconds where
> the CS didn't drop below 90k, but right now its at ~300 for over 30 seconds...
> I
When grilled further on (Mon, 18 Jul 2005 00:10:53 -0400),
Tom Lane <[EMAIL PROTECTED]> confessed:
> The context swap problem was no worse in 8.0 than in prior versions,
> so that hardly seems like a good explanation. Have you tried reverting
> to the cron-based vacuuming method you used in 7.4?
When grilled further on (Mon, 18 Jul 2005 00:18:30 -0400),
Tom Lane <[EMAIL PROTECTED]> confessed:
> Robert Creager <[EMAIL PROTECTED]> writes:
> > I am, and it is. It's ANALYZING and VACUUM'ing tables every interval (5 mi=
> > nutes
> > - 8.0.3).
When grilled further on (Sun, 17 Jul 2005 22:09:11 -0700),
"Jeffrey W. Baker" <[EMAIL PROTECTED]> confessed:
>
> Did you build 8.0.3 yourself, or install it from packages? I've seen in
> the past where pg would build with the wrong kind of mutexes on some
> machines, and that would send the CS t
When grilled further on (Mon, 18 Jul 2005 00:10:53 -0400),
Tom Lane <[EMAIL PROTECTED]> confessed:
> Have you tried reverting
> to the cron-based vacuuming method you used in 7.4?
>
I just stopped autovacuum, ran a manual vacuum analyze on 803 (2064 pages
needed, 800 FSM setting) and re-star
When grilled further on (Mon, 18 Jul 2005 16:17:54 +1200),
David Mitchell <[EMAIL PROTECTED]> confessed:
> Maybe you should check who is holding locks.
Hmmm... The only difference is how the vacuum is run. One by autovacuum, one
by cron (vacuum analyze every 5 minutes).
Cheers,
Rob
--
23:01
When grilled further on (Mon, 18 Jul 2005 00:18:43 -0400),
"Matthew T. O'Connor" confessed:
> Have you turned on the query logging to see what queries are
> taking so long?
>
Yeah. In the original message is a typical query. One from 741 and the other
on 803. On 803, an explain analyze is d
the query problem, and the CS numbers being high. 7.4.1
vacuums every 5 minutes always take < 30 seconds (when I'm watching).
Cheers,
Rob
When grilled further on (Sun, 17 Jul 2005 23:48:20 -0400),
"Matthew T. O'Connor" confessed:
> Robert Creager wrote:
>
> &g
Sigh...
I recently upgraded from 7.4.1 to 8.0.3. The application did not change. I'm
now running both database concurrently (on different ports, same machine) just
so I could verify the problem really exists.
The application is a custom test application for testing mechanical systems.
The run
When grilled further on (Tue, 19 Oct 2004 22:12:28 -0400),
Rod Taylor <[EMAIL PROTECTED]> confessed:
> > I've done some manual benchmarking running my script 'time script.pl'
> > I realise my script uses some of the time, bench marking shows that
> > %50 of the time is spent in dbd:execute.
> >
>
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 bee
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 informatio
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
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 o
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
Hey All,
I've implemented a couple of functions ala date_trunc (listed at the bottom). These
functions are executed every 5 minutes (date_trunc_minute) and every week
(date_trunc_week) across 16 different values. The problem is that they take way
too long to execute (nearly 7x the 'regular' dat
When grilled further on (Wed, 19 May 2004 22:42:26 -0400),
Tom Lane <[EMAIL PROTECTED]> confessed:
> Robert Creager <[EMAIL PROTECTED]> writes:
> > I just figured out what was causing the problem on my system Monday.
> > I'm using the pg_autovacuum daemon, and it
When grilled further on (Wed, 19 May 2004 21:20:20 -0400 (EDT)),
Bruce Momjian <[EMAIL PROTECTED]> confessed:
>
> Did we ever come to a conclusion about excessive SMP context switching
> under load?
>
I just figured out what was causing the problem on my system Monday. I'm using
the pg_autovac
When grilled further on (Sun, 02 May 2004 11:39:22 -0400),
Dave Cramer <[EMAIL PROTECTED]> confessed:
> Robert,
>
> The real question is does it help under real life circumstances ?
I'm not yet at the point where the CS's are causing appreciable delays. I
should get there early this week and w
Found some co-workers at work yesterday to load up my library...
The sample period is 5 minutes long (vs 2 minutes previously):
Context switches - avgmax
Default 7.4.1 code : 48784 107354
Default patch - 10 : 20400 28160
patch at 100 : 38574 85372
patch at
When grilled further on (Thu, 29 Apr 2004 11:21:51 -0700),
Josh Berkus <[EMAIL PROTECTED]> confessed:
> spins_per_delay was not beneficial. Instead, try increasing them, one step
> at a time:
>
> (take baseline measurement at 100)
> 250
> 500
> 1000
> 1500
> 2000
> 3000
> 5000
>
> ... until y
When grilled further on (Wed, 21 Apr 2004 10:29:43 -0700),
Josh Berkus <[EMAIL PROTECTED]> confessed:
> Dave,
>
> > After some testing if you use the current head code for s_lock.c which
> > has some mods in it to alleviate this situation, and change
> > SPINS_PER_DELAY to 10 you can drastically
When grilled further on (Mon, 19 Apr 2004 20:53:09 -0400),
Tom Lane <[EMAIL PROTECTED]> confessed:
> I wrote:
> > Here is a test case.
>
> Hmmm ... I've been able to reproduce the CS storm on a dual Athlon,
> which seems to pretty much let the Xeon per se off the hook. Anybody
> got a multiple O
When grilled further on (Wed, 7 Jan 2004 18:06:08 -0500),
Andrew Sullivan <[EMAIL PROTECTED]> confessed:
>
> We have lately had a couple of cases where machines either locked up,
> slowed down to the point of complete unusability, or died completely
> while using jfs. We are _not_ sure that jfs
On Thu, 17 Jul 2003 16:20:42 +0100
Adam Witney <[EMAIL PROTECTED]> said something like:
>
> Actually I am going through the same questions myself at the
> moment I would like to have a 2 disk RAID1 and a 4 disk RAID5, so
> need at least 6 disks
>
> Anybody have any suggestions or experie
40 matches
Mail list logo
