Hi,
First of all, thanks to everyone that provided pointers on this matter.
The route I chose to take was to make 2 tables. One is for cumulative
network stats; this table can be used for the weekly,monthly,yearly
reports. I also created a table for daily stats which will be dropped
at midnight ea
Paul Halliday wrote:
srcaddr VARCHAR(15),
dstaddr VARCHAR(15),
Are these ip-adresses? If they are, consider using UNSIGNED INT columns
and the INET_NTOA() and INET_ATON() funtions. It will save you a lot of
space, thus increase the amount of data your hw can handle.
They are indeed i
On 5/10/05, Roger Baklund <[EMAIL PROTECTED]> wrote:
> Paul Halliday wrote:
> > srcaddr VARCHAR(15),
> > dstaddr VARCHAR(15),
>
> Are these ip-adresses? If they are, consider using UNSIGNED INT columns
> and the INET_NTOA() and INET_ATON() funtions. It will save you a lot of
> spac
Paul Halliday wrote:
srcaddr VARCHAR(15),
dstaddr VARCHAR(15),
Are these ip-adresses? If they are, consider using UNSIGNED INT columns
and the INET_NTOA() and INET_ATON() funtions. It will save you a lot of
space, thus increase the amount of data your hw can handle.
I have read u
We did something similar for our large statistic tables. The older data
that no longer changes would get shipped off into a very fast read only
table with a cron job and then that is the table we would generate the
reports on. Even with millions of entries it is incredibly fast.
Eric Jensen
[EM
Hi,
you have to play with "explain" to see which index is used in your queries.
Since you defined only mono-column indexes, i think they are not used in
queries with multi-criteria search.
Consider adding indexes with all used columns and eventually drop the not used
ones to not slow updates and i
I'm somewhat a newbee on this database but some observations:
As your table grows (and indexes) INSERTS will definitly slow because of the
indexes.
Consider MySQL's version of Oracle's partitioning and using MERGE TABLES
"feature". Just remember that if you change 1 table, all of them have to b
On Tue, 2005-05-10 at 14:56 -0400, Frank Bax wrote:
> At 02:22 PM 5/10/05, Paul Halliday wrote:
> >Now, as time progresses the queires are getting slower and slower.
> >I know this is expected,
>
>
> I don't think so. I thought that if the number of rows returned does not
> change and an index
Don't forget to run an analyze to adjust the statistics for the
optimizer/indexes. Also, after any updates (on dynamic tables which yours is)
or any deletes run an optimize.
Quoting Paul Halliday <[EMAIL PROTECTED]>:
Hello,
I am working on a database that deals with network statistics. I have
a pr
At 02:22 PM 5/10/05, Paul Halliday wrote:
Now, as time progresses the queires are getting slower and slower.
I know this is expected,
I don't think so. I thought that if the number of rows returned does not
change and an index is properly used, then query time should not change
significantly as
Hello,
I am working on a database that deals with network statistics. I have
a program that generates web reports based on this data every ten
minutes.
The table layout looks something like this:
CREATE TABLE traffic
(
unix_secs INT UNSIGNED NOT NULL,
dpkts INT UNSIGNED NOT NULL
11 matches
Mail list logo
