Date
Attendees
Fabrice Jammes, Serge Monkewitz, Vaikunth Thukral, Andy Salnikov, Andy Hanushevsky, John Gates, Brian Van Klaveren, Unknown User (npease), Fritz Mueller, Jacek Becla
Discussion items
ORDER BY
- related tickets: DM-680 - Getting issue details... STATUS , DM-2859 - Getting issue details... STATUS
- query with "SELECT a FROM t ORDER BY b" very uncommon, don't spend time on it and don't complicate code to support it
- need access to schema to catch queries with ORDER BY that sorts by column which is not in SELECT
- access to schema will be needed for many other reasons, definitely worth implementing. ( DM-3109 - Getting issue details... STATUS created)
- If user query has "ORDER BY", then lua can't just execute "SELECT * FROM result" because the order for such query is not guaranteed. To fix that, we need to add "ORDER BY" clause to the "SELECT * FROM result" query on the lua side.
- DM-3104 - Getting issue details... STATUS created
IN2P3 cluster
- IN2P3 team wants weekly status how we used the cluster
CSS v2 (supporting updates)
- related ticket: DM-2966 - Getting issue details... STATUS
- issue: we take a snapshot, start using it, tables get deleted
- proposed solution:
- lock metadata (by setting special key in zookeeper as we do now)
- take snapshot
- register query in query metadata (includes information which tables are used by given query)
- release metadata lock
- nobody will delete tables when we are holding a lock, and nobody will delete tables as long as query metadata knows the tables are used by some queries. So this will work
- Issue: single lock per table might slow things down. Proposed solution: allow multiple read locks on the same table (one per query analysis)
- alternative solution: do the locking in mysql
- plan: keep thinking about the above, revisit next week.