Hi.
Unfortunately you posted only one of the queries, so one cannot weight
in their complexity.
First, normally forums get at least about 10 times more read requests
than new posts. In my experience posting speed is not a limiting
factor. That said, I am going to answer your original question.
I am not sure, why you need this GROUP BY query at all (and only for
posts)? Anyhow, the GROUP BY normally will be significantly slower
than running a simple select and update.
Regardless, you should always benchmark this yourself, as those
statements always depend on table sizes, indexes and so on.
Bye,
Benjamin.
On Thu, Apr 25, 2002 at 12:41:02PM -0400, [EMAIL PROTECTED] wrote:
> I am building a forum as part of a site, and the forum is broken into three
> tables, a forum table, a thread table, and a post table.
> All tables have indexes for common SELECT statements, to increase speed.
>
> Example-
> A user posts a new thread: One method would be 3 queries to insert/update
> (insert into post, insert into thread, update forum) and 1 simpler query to
> read (SELECT <<forum info and stats>>), and in another method, 2 queries to
> insert/update (insert into thread, insert into post) and one slightly more
> complex query to read, using a query similar to this: SELECT COUNT(*) AS
> totalreplies, postid, threadid, userid, username, posteddate FROM post GROUP
> BY posteddate ORDER BY posteddate DESC
>
> At smaller volumes the query times are all very similar and not very
> substantial. I'm curious as to what the fastest method would be, at higher
> volumes.
>
> Thanks in advance for any thoughts, ideas or info.
>
> Mike Grabski
--
[EMAIL PROTECTED]
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
