| 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-06 01:37:09 |
| Message-ID: | 4B91B1C5.3000707@postnewspapers.com.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 5/03/2010 10:09 PM, Ogden wrote:
> Would searching a huge table be as fast as calculating or about the same? I'll have to run some tests on my end but I am very impressed by the speed of which PostgreSQL executes aggregate functions.
I'm not sure what you're asking.
> Do you suggest looking at this option when we see the reporting to slow down? At that point do you suggest we go back to the drawing board?
If it ain't broke, don't fix it. However, it's a good idea to make it
easy to fix later - for example, wrap your score calculations up into a
view (see CREATE VIEW) so that you can replace it with a materialized
view later if you start seeing performance issues.
--
Craig Ringer
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Noah Misch | 2010-03-06 04:02:26 | 9.0 VACUUM FULL vs. ALTER TABLE? |
| Previous Message | Wang, Mary Y | 2010-03-06 01:05:57 | What's the best way to deal with the pk_seq sequence value after a restore (bulk loading)? |