final touces

Author: 0xBoxer

docs/query/query-executions.md

@@ -64,16 +64,21 @@ Query executions on Dune are triggered in four ways:
 
 Dune has three query engine sizes: community, medium, and large. The query engine size determines the amount of resources allocated to your query. The larger the query engine, the more resources are allocated to your query. This means that queries executed on a larger query engine will run faster and are less likely to time out.
 
-### Community engine
+<div style="position: relative; padding-bottom: calc(57.58333333333333% + 41px); height: 0; width: 100%"><iframe src="https://demo.arcade.software/qEa2Yifc6aUHvSO3p0QA?embed" frameborder="0" loading="lazy" webkitallowfullscreen mozallowfullscreen allowfullscreen style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;color-scheme: light;" title="Query engine size selector"></iframe></div>
+
+
+
+### Community engine (0 credits)
 
 The community engine is the default query engine for all queries on Dune. It is a shared cluster, meaning that it is used by all Dune users. This means that the community cluster can be busy at times, which can lead to long loading times for the viewer if the query is resource-intensive. In the worst case, the query may even time out.
 
-### Medium engine
+### Medium engine (10 credits)
 
 The medium engine is built to handle most queries on Dune. It is cheap, reliable and fast. The medium engine will scale up and down depening on the demand. In contrast to the community engine, that means that running a query on the medium engine will not be affected by other users' queries.
 
-### Large engine
+### Large engine (20 credits)
 
 The large engine is built to handle the most resource-intensive queries on Dune. It's blazing fast, reliable and can easily deal with large amounts of data. The large engine also scales up and down depending on the demand. Running a query on the large engine will not be affected by other users' queries.   
+
 In addition to that, the large engine is also the only engine that can handle queries that requires lots of planning time. This mostly happens when you query a large amount of data, when you use a lot of joins or large aggregate window functions.
 

docs/query/writing-efficient-queries.md

@@ -25,6 +25,8 @@ Each parquet file has a footer containing min/max values for every column stored
 
 However, the min/max values of strings, such as tx_hash strings and address strings in blockchain systems, are often not helpful, as they are randomly generated and not sequentially ordered. As a result, queries that reference these strings will be inefficient since all related pages need to be read into memory.
 
+![min/max values](../query/images/minmax-schema.jpg)
+
 ### Writing Efficient Queries
 
 To write efficient queries on DuneSQL, it's crucial to use filter conditions based on columns that are sequentially ordered and correlated with the file's sorting. Columns like `block_time` and `block_number` are suitable for this purpose. For instance, consider the following optimized query:
@@ -48,7 +50,7 @@ In addition to leveraging the columnar storage format and using sequentially ord
 
 2. **Use the LIMIT clause**: If you're only interested in a specific number of rows, use the LIMIT clause to avoid processing more data than necessary.
 
-3. **Leverage partition pruning**: If your data is partitioned, use partition keys in the WHERE clause to help the query engine prune unnecessary partitions and reduce the amount of data scanned.
+3. **Leverage partition pruning**: If your data is partitioned, use partition keys in the WHERE clause to help the query engine prune unnecessary partitions and reduce the amount of data scanned. In Dune almost all tables are partitioned by time and/or block number.
 
 4. **Filter early and use predicate pushdown**: Apply filters as early as possible in the query to reduce the amount of data being processed. This takes advantage of predicate pushdown, which pushes filter conditions down to the storage layer, reducing the amount of data read from storage.
 
@@ -58,8 +60,6 @@ In addition to leveraging the columnar storage format and using sequentially ord
 
 7. **Optimize subqueries**: Subqueries can sometimes cause performance issues. Consider using Common Table Expressions (CTEs) or rewriting the query using JOINs to optimize subqueries.
 
-8. **Use the EXPLAIN command**: The EXPLAIN command shows the query execution plan, which can help you understand the underlying operations and optimize your query. Analyze the output of EXPLAIN to identify potential bottlenecks or improvements.
-
-9. **Optimize data types**: Use appropriate data types for your columns, as it can improve query performance by reducing the amount of data processed. For example, varbinary operations are faster that varchar so be careful casting around too much.
+8. **Optimize data types**: Use appropriate data types for your columns, as it can improve query performance by reducing the amount of data processed. For example, varbinary operations are faster that varchar so be careful casting around too much.
 
 By following these tips, you can write more efficient queries on DuneSQL with TrinoSQL and optimize the performance of your data processing tasks. Remember that DuneSQL's unique structure, such as the parquet file format and columnar storage, should be taken into account when optimizing your queries to fully benefit from the system's capabilities.