[Chris - Fri at 02:32:05PM +1100]
> Not really. A bad query is a bad query (eg missing a join element). It
> won't show up for 3000 rows, but will very quickly if you increase that
> by a reasonable amount. Even as simple as a missing index on a join
> column won't show up for a small dataset bu
Tobias Brox wrote:
[EMAIL PROTECTED] - Thu at 06:37:12PM -0600]
As my dataset has gotten larger I have had to throw more metal at the
problem, but I have also had to rethink my table and query design. Just
because your data set grows linearly does NOT mean that the performance of
your query is
David Boreham wrote:
These number look a bit strange. I am wondering if there is a hardware
problem on one of the drives
or on the controller. Check in syslog for messages about disk timeouts
etc. 100% util but 6 writes/s
is just wrong (unless the drive is a 1980's vintage floppy).
Agreed
Carlos H. Reimer wrote:
avg-cpu: %user %nice %system %iowait %idle
50.400.000.501.10 48.00
Device:rrqm/s wrqm/s r/s w/s rsec/s wsec/srkB/swkB/s
avgrq-sz avgqu-sz await svctm %util
sda 0.00 7.80 0.40 6.40 41.60 113.60
Carlos H. Reimer wrote:
While collecting performance data I discovered very bad numbers in the
I/O subsystem and I would like to know if I´m thinking correctly.
Here is a typical iostat -x:
avg-cpu: %user %nice %system %iowait %idle
50.400.000.501.10 48.00
[EMAIL PROTECTED] - Thu at 06:37:12PM -0600]
> As my dataset has gotten larger I have had to throw more metal at the
> problem, but I have also had to rethink my table and query design. Just
> because your data set grows linearly does NOT mean that the performance of
> your query is guaranteed to
> 4) Much of my reading of the PG docs and list archives seems to suggest
that much of performance tuning is done at the query level - you have to
know how to ask for information in an efficient way.
Performance does not exist in a vacuum (ho ho, PostgreSQL joke). The
person writing the queries h
[Jeff Davis - Thu at 04:57:54PM -0800]
> > We're having the same issues, so we do the dumping and restoring every
> > now and then to be sure everything is properly cleaned up. With 8.1.
> >
>
> What's causing that? Is it index bloat?
>
> I would think a REINDEX would avoid having to dump/resto
On Fri, 2006-12-01 at 01:05 +0100, Tobias Brox wrote:
> > However, we still are suffering a gradual decrease in performance over
> > time - or so the application engineers claim. The DBA and I have been
> > banging our heads against this for a month.
>
> We're having the same issues, so we do the
Hi,
I was called to find out why one of our PostgreSQL servers has not a
satisfatory response time. The server has only two SCSI disks configurated
as a RAID1 software.
While collecting performance data I discovered very bad numbers in the I/O
subsystem and I would like to know if I´m thinking co
On Thu, 2006-11-30 at 18:26, Tom Lane wrote:
> Paul Lathrop <[EMAIL PROTECTED]> writes:
> > ... When I joined the company last year, the databases were
> > deployed on 12-disk RAID5 arrays on dual-proc AMD machines with 4Gb of
> > RAM, running Debian Woody and Postgres 7.2. These systems seemed to
Paul Lathrop <[EMAIL PROTECTED]> writes:
> ... When I joined the company last year, the databases were
> deployed on 12-disk RAID5 arrays on dual-proc AMD machines with 4Gb of
> RAM, running Debian Woody and Postgres 7.2. These systems seemed to
> suffer a gradually decreasing performance accompani
[Paul Lathrop - Thu at 02:59:27PM -0800]
> growing disk space usage. The DBA had come to the conclusion that the
> VACUUM command did/does not work on these systems, because even after a
> VACUUM FULL, the size of the database was continually increasing. So, as
> things stand with the PG7.2 machine
Hello all,
I've been struggling with some performance questions regarding our
Postgres databases. Here's the background:
We run 4 ~25-30Gb databases which cache information from eBay. These
databases have had performance issues since before I joined the company.
The databases have gone through a
14 matches
Mail list logo
