From: | Christian Fowler <spider(at)steelsun(dot)com> |
---|---|
To: | Shane|SkinnyCorp <shanew(at)skinnycorp(dot)com> |
Cc: | PgSQL ADMIN <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: PLEASE GOD HELP US! |
Date: | 2004-10-01 19:25:06 |
Message-ID: | Pine.LNX.4.61.0410011514150.8260@leda.steelsun.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Hi Shane,
As many others have alluded to - performance like this is almost always
attributable to your queries not using an index. Be it on Oracle, Mysql,
or postgres, i have seen this problem popup often.
Also, could you tell us what language you are using, and if you are using
a DB abstraction layer?
On to the particulars:
> # WEBSITE #
>
> # SAMPLE DUMP OF COMMON PAGE-SPECIFIC QUERIES
>
> 8 Queries Totaling 10.7413 Seconds
Since one query is taking 90% of the time, it clearly is the first
cuplrit:
> SQL: SELECT * FROM thread_listing AS t ORDER BY t.status=5
> DESC,t.lastreply desc LIMIT 25 OFFSET 0
> Num Rows: 25
> Affected Rows: 0
> Exec Time: 9.1602659225464
Your SQL here seems what I would consider not typical. I would write it
as:
SELECT * FROM thread_listing AS t WHERE t.status=5 ORDER BY t.lastreply
desc LIMIT 25 OFFSET 0;
Run that from a psql shell, and see if that speed things up. If not, run:
db=> EXPLAIN ANALYSE SELECT * FROM thread_listing AS t WHERE t.status=5
ORDER BY t.lastreply desc LIMIT 25 OFFSET 0;
and
db=> \d thread_listing
And send it to the list. You are in good shape I think, and porting won't
be necessary. I've used many db's and postgres is my favorite by far. I'd
say you've made a good choice ;-)
[ \ /
[ >X< spider(at)steelsun(dot)com | http://www.steelsun.com/
[ / \
From | Date | Subject | |
---|---|---|---|
Next Message | Christian Fowler | 2004-10-01 20:04:35 | Re: PLEASE GOD HELP US! |
Previous Message | Shane | SkinnyCorp | 2004-10-01 19:19:29 | Re: PLEASE GOD HELP US! |