Paul Lathrop wrote:
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 number of iterations. Initially, they
were deployed as one huge database - performance was apparently
[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
[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
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
11 matches
Mail list logo
