Re: Tuning scenarios (was Changing the default configuration)

From: johnnnnnn <john(at)phaedrusdeinus(dot)org>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Tuning scenarios (was Changing the default configuration)
Date: 2003-02-14 16:33:14
Message-ID: 20030214163314.GK11017@performics.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-hackers pgsql-performance

On Fri, Feb 14, 2003 at 03:48:43AM -0800, Kevin Brown wrote:
> That unfortunately doesn't help us a whole lot in figuring out
> defaults that will perform reasonably well under broad conditions,
> unless there's some way to determine a reasonably consistent pattern
> (or set of patterns) amongst a lot of those applications.

When moving to a new DB or DB box, we always run a series of
benchmarks to make sure there aren't any surprises
performance-wise. Our database activity, and thus our benchmarks, are
broken up into roughly three different patterns:

1- Transaction processing: small number of arbitrary small
(single-row) selects intermixed with large numbers of small inserts
and updates.

2- Reporting: large reads joining 6-12 tables, usually involving
calculations and/or aggregation.

3- Application (object retrieval): large numbers of arbitrary,
single-row selects and updates, with smaller numbers of single row
inserts.

We use our own application code to do our benchmarks, so they're not
general enough for your use, but it might be worthwhile to profile
each of those different patterns, or allow DB admins to limit it to a
relevant subset. Other patterns i can think of include logging (large
number of single row inserts, no updates, occasional large, simple
(1-3 table) selects), mining (complicated selects over 10 or more
tables), automated (small inserts/updates, with triggers cascading
everywhere), etc.

The problem becomes dealing with the large amounts of data necessary
to frame all of these patterns. An additional wrinkle is accomodating
both columns with well-distributed data and columns that are top-heavy
or which only have one of a small number of values. Plus indexed vs
unindexed columns.

Or, somewhat orthogonally, you could allow pgbench to take a workload
of different sql statements (with frequencies), and execute those
statements instead of the built-in transaction. Then it would be easy
enough to contribute a library of pattern workloads, or for the DBA to
write one herself.

Just my two cents.

-johnnnnnnnnnn

In response to

Browse pgsql-advocacy by date

  From Date Subject
Next Message Josh Berkus 2003-02-14 17:36:02 Re: Tuning scenarios (was Changing the default configuration)
Previous Message Robert Treat 2003-02-14 15:59:12 Re: [HACKERS] Changing the default configuration

Browse pgsql-hackers by date

  From Date Subject
Next Message Oliver Elphick 2003-02-14 16:44:49 Re: location of the configuration files
Previous Message Tom Lane 2003-02-14 16:32:02 Re: psql and readline

Browse pgsql-performance by date

  From Date Subject
Next Message Scott Cain 2003-02-14 16:44:00 performace problem after VACUUM ANALYZE
Previous Message Tom Lane 2003-02-14 15:07:45 Re: Offering tuned config files