Re: Where do a novice do to make it run faster?

From: PFC <lists(at)peufeu(dot)com>
To: "A B" <gentosaker(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Where do a novice do to make it run faster?
Date: 2008-04-28 18:23:12
Message-ID: op.uab2oycdcigqcu@apollo13.peufeu.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


You got the order slightly wrong I guess.

> 1) hardware

Would only come first if your RAM is really too small, or you use RAID5
on write-heavy tables, or what limits you is transaction fsync (hint :
8.3).
Adding RAM is cheap.

> 2) rewriting my queries and table structures

This should really come first.
Log expensive queries. Note that an expensive query can be a slow query,
or be a rather fast query that you execute lots of times, or a very simple
and fast query that you execute really really too often.

Now ask yourself :
* What is this query supposed to do ?

* Do I need this query ?

Example :
You put your sessions in a database ?
=> Perhaps put them in the good old filesystem ?

Your PHP is loading lots of configuration from the database for every
page.
=> Cache it, generate some PHP code once and include it, put it in the
session if it depends on the user, but don't reload the thing on each page
!

This feature is useless
=> Do you really need to display a birthday cake on your forum for those
users who have their birthday today ?

UPDATEs...
=> Do you really need to update the last time a user was online every
time ? What about updating it every 5 minutes instead ?

* Is this query inside a loop ?
=> Use JOIN.

* Do I need all the rows from this query ?

Example :
You use pagination and perform the same query changing LIMIT/OFFSET ?
=> Perform the query once, retrieve the first N pages of result, cache it
in the session or in a table.

* You have a website ?
=> Use lighttpd and fastcgi

* Do I need all the columns from this query ?

* Do I suffer from locking ?

etc.

Now you should see some easy targets.
For the queries that are slow, use EXPLAIN ANALYZE.
Question your schema.
etc.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Gregory Stark 2008-04-28 18:40:25 Re: Benchmarks WAS: Sun Talks about MySQL
Previous Message Greg Smith 2008-04-28 18:16:02 Re: Very poor performance loading 100M of sql data using copy