Tag Info

New answers tagged

1

TokuDB is a storage engine in MariaDB, as is XtraDB/Aria/MyISAM. Queries are planned by the upper layers of MariaDB (and MySQL) calling into the storage engine to help it make decisions about optimization. What you need to do is create your tables and load your data create the indexes you think will help optimize your query workload run your queries with ...


5

Well, you could consider a filtered index - if you're always looking for rows where IsSynchronized = 0 and this number should be relatively small, then instead of those two indexes, consider this instead: CREATE NONCLUSTERED INDEX [IX_NotSynchronized] ON [dbo].[PackageEvents] ([PackageID]) INCLUDE ([EventDate], [EventDescription], [EventID], ...


3

Without seeing the actual query and plan, we are shooting in the dark. Depending on how the query is actually written, it might benefit from an index such as: CREATE NONCLUSTERED INDEX [IX_IsSynchronized_PackageID_etc] ON [dbo].[PackageEvents] ( [IsSynchronized] , [PackageID] ) INCLUDE ( [EventDate] , [EventDescription] , [EventID] ...


0

Why don't your input parameters match the type for the table? Why would you want to keep the wrong types there and perform any casts or conversions at all (whether implicit or explicit)? Why are you converting anything to FLOAT, of all things? To address specific questions: My query says [low] is being converted from int to numeric but that doesn't seem ...


1

Since phone_number is the field with high cardinality, I would try putting an index on that. If your performance is still poor, I would try adding campaign_id and the other output fields (id, last_attempt_time, call_time) to your index, so there's no need to hit the actual table at all.


1

If the IN value list is only up to 3 items, you can rewrite with UNION. The query will have to be build dynamically, either in some other language or with dynamic SQL but it will have only equiality conditions and should not do a table scan: SELECT id, phone_number, last_attempt_time FROM ( SELECT id, phone_number, last_attempt_time, call_time FROM ...


1

I'm not a Postgres guy, but with other DBs this can be a problem with the table statistics that the query planner relies on. Resetting those via an ANALYZE TABLE can resolve the issue. Your queries & indexes look correct. http://www.postgresql.org/docs/9.0/static/sql-analyze.html


4

To answer your second question: MySQL does not have a parallel query execution engine, so even if you partition the query, you are still single threaded. This will eventually kill your scale. However, you could partition the table by visitor_id. This would allow you to run several queries (one per partition) in parallel, all of them form: SELECT ...



Top 50 recent answers are included