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...
It's bouncing all over the place,
On 7/15/05, Bruno Wolff III [EMAIL PROTECTED] wrote:
On Thu, Jul 14, 2005 at 16:29:58 -0600,
Dan Harris [EMAIL PROTECTED] wrote:
Ok, I tried this one. My ssh keeps getting cut off by a router
somewhere between me and the server due to inactivity timeouts, so
all I know is that both
Robert Creager [EMAIL PROTECTED] writes:
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?
I've
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 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, or
Robert Creager [EMAIL PROTECTED] writes:
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, or do I need a
Tom Lane wrote:
Robert Creager [EMAIL PROTECTED] writes:
I've vacuum_cost_delay = 10 in the conf file for 803.
Hmm, did you read this thread?
http://archives.postgresql.org/pgsql-performance/2005-07/msg00088.php
It's still far from clear what's going on there, but it might be
Just out of curiosity, does it do any better with the following?
SELECT ...
FROM a
JOIN b ON (a.key = b.key)
LEFT JOIN c ON (c.key = a.key)
LEFT JOIN d ON (d.key=a.key)
WHERE (b.column = 100)
Dario Pudlo [EMAIL PROTECTED] 07/06/05 4:54 PM
(first at all, sorry for
On 7/18/05, Tom Lane [EMAIL PROTECTED] wrote:
Christopher Petrilli [EMAIL PROTECTED] writes:
http://blog.amber.org/diagrams/comparison_mysql_pgsql.png
Notice the VERY steep drop off.
Hmm. Whatever that is, it's not checkpoint's fault. I would interpret
the regular upticks in the
On Jul 17, 2005, at 1:08 PM, Christopher Petrilli wrote:
Normally, checkpoint_segments can help absorb some of that, but my
experience is that if I crank the number up, it simply delays the
impact, and when it occurs, it takes a VERY long time (minutes) to
clear.
There comes a point where
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 leading
On 7/18/05, Vivek Khera [EMAIL PROTECTED] wrote:
On Jul 17, 2005, at 1:08 PM, Christopher Petrilli wrote:
Normally, checkpoint_segments can help absorb some of that, but my
experience is that if I crank the number up, it simply delays the
impact, and when it occurs, it takes a VERY long
Robert Creager [EMAIL PROTECTED] writes:
Around 8:15 I was starting to receive hits of a few seconds of high CS hits,
higher than the previous 7 hour run on 741. I changed the vacuum delay to 0
and
HUP'ed the server (how can I see the value vacuum_cost_delay run
time?).
Start a fresh psql
Hi,
Suppose I have a table with 4 fields (f1, f2, f3, f4)
I define 2 unique indexes u1 (f1, f2, f3) and u2 (f1, f2, f4)
I have 3 records
A, B, C, D (this will be inserted)
A, B, C, E (this will pass u2, but not u1, thus not inserted)
A, B, F, D (this will pass u1, but not u2, thus not inserted)
Christopher Petrilli [EMAIL PROTECTED] writes:
http://blog.amber.org/diagrams/comparison_mysql_pgsql.png
Notice the VERY steep drop off.
Hmm. Whatever that is, it's not checkpoint's fault. I would interpret
the regular upticks in the Postgres times (every several hundred
iterations) as being
Hi.
Just out of curiosity, does it do any better with the following?
SELECT ...
Yes, it does.
But my query could also be
SELECT ...
FROM a
JOIN b ON (a.key = b.key)
LEFT JOIN c ON (c.key = a.key)
LEFT JOIN d ON (d.key=a.key)
/*new*/ , e
WHERE (b.column = 100)
Christopher Petrilli [EMAIL PROTECTED] writes:
On 7/18/05, Tom Lane [EMAIL PROTECTED] wrote:
I have no idea at all what's causing the sudden falloff in performance
after about 1 iterations. COPY per se ought to be about a
constant-time operation, since APPEND is (or should be)
17 matches
Mail list logo
