That's quite a query. You may not be able to optimize it well with
those nested selects. You may want to think about changing your query
around a little, perhaps joining pieces of data using whatever
programming language you're using on the front end. You have MySQL
doing a lot of work and
On 6/27/07, Dave G <[EMAIL PROTECTED]> wrote:
select payload_time,HEX(processed_data) from data__ProcessedDataFrames
where test_id=18 AND top_level_product_name="DataProduct" AND payload_time
> 11808.74704 AND payload_time < 1180564096.24967;
What I'm concerned about is with how much data I
I do, but I don't see any way around that with the data I have.
Dave G.
> Good Afternoon David
>
> sounds as if you have a number of non-unique indices (even possibly FTS!)
> slowing down queries..this should help you concentrate on the slower
> indices
> mysql>
> select TABLE_NAME,COLUMN_NAME,IN
I think I can do that:
I don't have any other indexes, just the keys.
mysql> show create table data__ProcessedDataFrames;
+---+--
Good Afternoon David
sounds as if you have a number of non-unique indices (even possibly FTS!)
slowing down queries..this should help you concentrate on the slower indices
mysql>
select TABLE_NAME,COLUMN_NAME,INDEX_NAME from INFORMATION_SCHEMA.STATISTICS
where NON_UNIQUE=1;
Anyone else?
Mart
On 6/27/07, Dave G <[EMAIL PROTECTED]> wrote:
Queries on this table when it gets large is slow as molasses. I'm
thinking about making a new table for anything with a different test_id
any opinions as to whether this is good or bad?
Hi Dave G.,
We need to know how:
a)How large the tabl
On Jan 12, 2004, at 08:09 AM, Douglas Sims wrote:
I think... you don't have an index on the "Incident" field itself,
just on (Date, Incident, Type, Task) which means that it concatenates
those fields and orders the result - thus this may be virtually
useless if you're looking for a specific inc
I think... you don't have an index on the "Incident" field itself, just
on (Date, Incident, Type, Task) which means that it concatenates those
fields and orders the result - thus this may be virtually useless if
you're looking for a specific incident within a large date range. Since
your query
