Bob Terrell wrote:
on 1/2/04 12:59 PM, Adam i Agnieszka Gasiorowski FNORD wrote:
Thanks for the info. Just so I'm sure I know what I should: :)
Thanks for your answer, very helpful!
?
$suma = 0;
For starters, you won't need this line anymore. You'll see why in a minute.
Bob Terrell wrote:
So there you go. Give it a shot and see if it runs any faster. If you need the time,
replace that first test in the WHERE clause with the one mentioned above. If this is
run often (or if it just takes a _really_ long time), put an index on the date
field, if one isn't
Bob Terrell wrote:
on 1/2/04 12:59 PM, Adam i Agnieszka Gasiorowski FNORD wrote:
Tell me if you need any additional information.
Thank you for all your help.
Some additional information would help, yes. What exactly are the sections, for
example? Do you need to know the number of new
on 1/2/04 12:59 PM, Adam i Agnieszka Gasiorowski FNORD wrote:
Thanks for the info. Just so I'm sure I know what I should: :)
1) You only want the day's articles. These are records in the article table and
nowhere else.
2) An article will always belong to at least one section, and may belong to
I need help width formulating the most
effective (in terms of processing time)
SQL query to count all the new
documents in the repository, where new is
defined as from 00:00:01 up to 23:59:59
today. My current query does not give me
satisfactory results, it creates a
One other thing to check is that there are indexes on the fields in the other tables
that you are joining to.
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
on 1/2/04 12:59 PM, Adam i Agnieszka Gasiorowski FNORD wrote:
Tell me if you need any additional information.
Thank you for all your help.
Some additional information would help, yes. What exactly are the sections, for
example? Do you need to know the number of new _articles_ total, the new
In all probability it's (x_section.Status 1) = 0 and
(x_instance.Status 255) = 0 that's giving you the problem.
Unfortunately this is a database schema problem not a query fix. By putting
a computation on a field into the WHERE clause, you're forcing the database
to do that computation on