Open bonesmoses opened 9 years ago
As you've already discovered, enabling auto_explain
on worker nodes is one workaround, but that's not very proactive.
Which shards would the query run on? How much data came from each candidate shard?
I agree that a "just ask a shard" approach is a nice first pass, but as you've noted, more advanced capabilities are possible if we keep statistics about the shards. CitusDB does this to help plan distributed joins (especially important is just the shard size), and I think pg_shard
could benefit from a bit of that as well.
Currently when an
EXPLAIN
is applied to a query, the following output is produced:This makes it effectively impossible to troubleshoot queries on tables using
pg_shard
. Even something as simple as executing theEXPLAIN
on candidate worker nodes and combining the results would be sufficient as a replacement for this error.