we're now at a stage so we can test/benchmark scan/scan queries, i.e push most queries. there are still know bugs and things that we can't push.
to see how we performs, we tested a very old query/dataset, that a customer tried in the 4.1 days. the result at that time was a disaster, and they at that time decided to use something else.
it's a 11-way join with mainly REF accesses (i.e not many lookups)
i tested it on same hardware/configuration as for my UC presentation.
without join pushdown the average query time is 3.6s.
with join pushdown it's ~500ms, i.e ~7x improvement.
the nights of kni are deeply disappointed, and that's an attitude i like :-)
FYI: we also optimized TPCW::getBestSeller some more and are now at 42x on that hardware/configuration.
---
stay tuned
---
micro update: Found a bug when using ndbmtd...fixing that gave 200ms (i.e 18x)...also did some more optimizations and now record is 120ms (i.e 29x)![]()
PlanetMySQL Voting: Vote UP / Vote DOWN
to see how we performs, we tested a very old query/dataset, that a customer tried in the 4.1 days. the result at that time was a disaster, and they at that time decided to use something else.
it's a 11-way join with mainly REF accesses (i.e not many lookups)
i tested it on same hardware/configuration as for my UC presentation.
without join pushdown the average query time is 3.6s.
with join pushdown it's ~500ms, i.e ~7x improvement.
the nights of kni are deeply disappointed, and that's an attitude i like :-)
FYI: we also optimized TPCW::getBestSeller some more and are now at 42x on that hardware/configuration.
---
stay tuned
---
micro update: Found a bug when using ndbmtd...fixing that gave 200ms (i.e 18x)...also did some more optimizations and now record is 120ms (i.e 29x)
PlanetMySQL Voting: Vote UP / Vote DOWN