Re: Optimizations

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: Ogden <lists(at)darkstatic(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Optimizations
Date: 2010-03-05 08:26:46
Message-ID: 4B90C046.8080508@postnewspapers.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Ogden wrote:
> We run a student scoring system with PostgreSQL as a backend. After the results for each student are inputted into the system, we display many reports for them. We haven't had a problem with efficiency or speed, but it has come up that perhaps storing the rolled up scores of each student may be better than calculating their score on the fly. I have always coded the SQL to calculate on the fly and do not see any benefit from calculating on the fly. For a test with over 100 questions and with 950 students having taken it, it calculates all their relevant score information in less than half a second. Would there be any obvious benefit to caching the results?

Caching the results would mean storing the same information in two
places (individual scores, and aggregates calculated from them). That's
room for error if they're permitted to get out of sync in any way for
any reason. For that reason, and because it's complexity you don't need,
I'd avoid it unless I had a reason not to.

On the other hand if you expect the number of students you have to
report on to grow vastly then it's worth considering.

If you do go ahead with it, first restructure all queries that use that
information so they go view a view that calculates that data on the fly.

Then look at replacing that view with a table that's automatically
updated by triggers when the data source is updated (say, a student has
a new score recorded).

--
Craig Ringer

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Scott Marlowe 2010-03-05 08:31:40 Re: ERROR: row is too big: size 8176, maximum size 8160
Previous Message Ogden 2010-03-05 08:17:04 Optimizations