phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject [DISCUSS] EXPLAIN'ing what we do well (was Re: [DISCUSS] Suggestions for Phoenix from HBaseCon Asia notes)
Date Mon, 27 Aug 2018 22:01:42 GMT
On 8/27/18 5:03 PM, Thomas D'Silva wrote:
>> 3. Better recommendations to users to not attempt certain queries.
>> We definitively know that there are certain types of queries that Phoenix
>> cannot support well (compared to optimal Phoenix use-cases). Users very
>> commonly fall into such pitfalls on their own and this leaves a bad taste
>> in their mouth (thinking that the product "stinks").
>> Can we do a better job of telling the user when and why it happened? What
>> would such a user-interaction model look like? Can we supplement the "why"
>> with instructions of what to do differently (even if in the abstract)?
> Providing relevant feedback before/after a query is run in general is very
> hard to do. If stats are enabled we have an estimate of how many rows/bytes
> will be scanned.
> We could have an optional feature that prevent users from running queries
> if the rows/bytes scanned are above a certain threshold. We should also
> enhance our explain
> plan documentation  with example
> of queries so users know what kinds of queries Phoenix handles well.

Breaking this out..

Totally agree -- this is by no means "easy". I struggle very often 
trying to express just _why_ a query that someone is running in Phoenix 
doesn't run as well as they think it should.

Centralizing on the EXPLAIN plan is good. Making sure it's 
consumable/thorough is probably the lowest hanging fruit. If we can give 
concrete examples to the kinds of explain plans a user might see, I 
think that might get use from users/admins.

Throwing a random idea out there: with stats and the query plan, can we 
give a thumbs-up/thumbs-down? If we can, is that useful?

View raw message