On Sun, May 15, 2005 at 08:26:02PM -0700, Josh Berkus wrote:
> David,
>
> > I've seen these messages in the log before, and am aware of the need to
> > increase checkpoint_segments, but I wasn't aware that recycling a
> > transaction log could be that damaging to performance. There may have
> > be
On Sun, May 15, 2005 at 08:22:13PM -0400, David Parker wrote:
> In the database log at that time there was a "recycling transaction log"
> message which seems to correspond to the time when the clients were
> paused, though I don't have it concretely correlated.
Maybe what you need is make the b
"David Parker" <[EMAIL PROTECTED]> writes:
> I was recently running a test with multiple client shell processes
> running psql commands (inserts) when all the client processes appeared
> to hang simultaneously. I assumed that I had an application deadlock
> somewhere, but after a few seconds - less
David,
> I've seen these messages in the log before, and am aware of the need to
> increase checkpoint_segments, but I wasn't aware that recycling a
> transaction log could be that damaging to performance. There may have
> been some local hiccup in this case, but I'm wondering if recycling is
> kn
William,
> I'm sure there's some corner case where more memory helps.
QUite possibly. These were not scientific tests.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Actually, that solution didn't work so well. Even very small delays
in the loop caused the entire loop to perform too slowly to be useful
in the production environment. I ended up producing a small patch out
of it :P, but we ended up using pgpool to reduce connections from
another part of t
Mindaugas Riauba wrote:
The "vacuum cost" parameters can be adjusted to make vacuums fired
by pg_autovacuum less of a burden. I haven't got any specific numbers
to suggest, but perhaps someone else does.
It looks like that not only vacuum causes our problems. vacuum_cost
seems to lower vacuu
I was recently
running a test with multiple client shell processes running psql commands
(inserts) when all the client processes appeared to hang simultaneously. I
assumed that I had an application deadlock somewhere, but after a few seconds -
less than a minute, but certainly noticeable - a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Guillaume Nobiron wrote:
| Hi,
|
| Environment :
| - Fedora Core 2 (kernel 2.6.10)
| - postgresql 7.4.7
|
| I am running a huge query with several joins that needs around 900
| Mbytes of Memory (System RAM is 512 Mbytes).
|
| When the system starts to
I'm sure there's some corner case where more memory helps. If you
consider that 1GB of RAM is about $100, I'd max out memory on the
controller just for the hell of it.
Josh Berkus wrote:
Steve,
Past recommendations for a good RAID card (for SCSI) have been the LSI
MegaRAID 2x. This unit comes w
I say most apps because it's true. :) I would suggest that pretty much
every app (other than video/audio streaming) people think are
bandwidth-limited are actually latency-limited. Take the SpecFoo tests.
Sure I would have rather seen SAP/TPC/etc that would be more relevant to
Postgres but ther
William Yu <[EMAIL PROTECTED]> writes:
> It turns out the latency in a 2xDC setup is just so much lower and most apps
> like lower latency than higher bandwidth.
You haven't tested anything about "most apps". You tested what the SpecFoo
apps prefer. If you're curious about which Postgres prefers
Sorry for not listing the exact layout of temp_:
obsdb=> \d temp_dry_at_2m
Table "public.temp_dry_at_2m"
Column | Type | Modifiers
+-+---
obshist_id | integer | not nul
I wanted to get some opinions about row prefetching. AFAIK, there is no
prefetching done by PostgreSQL; all prefetching is delegated to the operating
system.
The hardware (can't say enough good things about it):
Athlon 64, dual channel
4GB ram
240GB usable 4 disk raid5 (ATA133)
Fedora Core 3
Hi,
Look for my comments further down...
John A Meinel wrote:
Kim Bisgaard wrote:
Hi,
I'm having problems with the query optimizer and FULL OUTER JOIN on
PostgreSQL 7.4. I cannot get it to use my indexes with full outer joins.
I might be naive, but I think that it should be possible?
I have two BIG
Hi,
Environment :
- Fedora Core 2 (kernel 2.6.10)
- postgresql 7.4.7
I am running a huge query with several joins that needs around 900
Mbytes of Memory (System RAM is 512 Mbytes).
When the system starts to swap the postgres process, CPU consumed drops
to around 2% (instead of around 50% on an
16 matches
Mail list logo
