Dan Harris [EMAIL PROTECTED] writes:
I keep the entire database vacuumed regularly.
How often is regularly? We get frequent posts from people who think daily or
every 4 hours is often enough. If the table is very busy you can need vacuums
as often as every 15 minutes.
Also, if you've done
On Thu, Jul 14, 2005 at 12:28:05AM -0600, Dan Harris wrote:
Ok, so I remounted this drive as ext2 shortly before sending my first
email today. It wasn't enough time for me to notice the ABSOLUTELY
HUGE difference in performance change. Ext3 must really be crappy
for postgres, or at
On Jul 14, 2005, at 9:47 AM, Alvaro Herrera wrote:
On Thu, Jul 14, 2005 at 12:28:05AM -0600, Dan Harris wrote:
. Ext3 must really be crappy
for postgres, or at least is on this box.
Were you using the default journal settings for ext3?
Yes, I was. Next time I get a chance to reboot
Dan Harris [EMAIL PROTECTED] writes:
Well, once every day, but there aren't a ton of inserts or updates going on a
daily basis. Maybe 1,000 total inserts?
It's actually deletes and updates that matter. not inserts.
I have a feeling I'm going to need to do a cluster soon. I have done
Gurus,
A table in one of my databases has just crossed the 30 million row
mark and has begun to feel very sluggish for just about anything I do
with it. I keep the entire database vacuumed regularly. And, as
long as I'm not doing a sequential scan, things seem reasonably quick
most of
On Jul 13, 2005, at 1:11 PM, John A Meinel wrote:
I might be wrong, but there may be something much more substantially
wrong than slow i/o.
John
Yes, I'm afraid of that too. I just don't know what tools I should
use to figure that out. I have some 20 other databases on this
system,
* Dan Harris ([EMAIL PROTECTED]) wrote:
On Jul 13, 2005, at 1:11 PM, John A Meinel wrote:
I might be wrong, but there may be something much more substantially
wrong than slow i/o.
Yes, I'm afraid of that too. I just don't know what tools I should
use to figure that out. I have some 20
On Wed, Jul 13, 2005 at 01:16:25PM -0600, Dan Harris wrote:
On Jul 13, 2005, at 1:11 PM, John A Meinel wrote:
I might be wrong, but there may be something much more substantially
wrong than slow i/o.
Yes, I'm afraid of that too. I just don't know what tools I should
use to figure that
On Jul 13, 2005, at 2:17 PM, Stephen Frost wrote:
Could you come up w/ a test case that others could reproduce where
explain isn't returning?
This was simply due to my n00bness :) I had always been doing
explain analyze, instead of just explain. Next time one of these
queries comes up,
On Jul 13, 2005, at 2:54 PM, Dan Harris wrote:
4 x 2.2GHz Opterons
12 GB of RAM
4x10k 73GB Ultra320 SCSI drives in RAID 0+1
1GB hardware cache memory on the RAID controller
if it is taking that long to update about 25% of your table, then you
must be I/O bound. check I/o while you're
On Wed, 2005-07-13 at 12:54 -0600, Dan Harris wrote:
For example, as I'm writing this, I am running an UPDATE statement
that will affect a small part of the table, and is querying on an
indexed boolean field.
An indexed boolean field?
Hopefully, ftindex is false for very few rows of the
11 matches
Mail list logo
