Changes between Version 4 and Version 5 of OtherDevelopments

Timestamp:

06/04/26 22:47:07 (2 weeks ago)

Author:

221296

Comment:

--

OtherDevelopments

@@ -3 +3 @@
 The performance analysis in this phase focuses on the two most complex analytical queries developed in Phase 6.
 
-Instead of analyzing simple CRUD operations, we analyzed the most computationally expensive reports in the system. The goal was to identify the most expensive JOIN operations, grouping operations and date-based aggregations, and then improve their execution using indexes.
+Instead of analyzing simple CRUD operations, we analyzed the most computationally expensive reports in the system. The goal was to identify the most expensive JOIN operations, grouping operations and date-based aggregations, and evaluate whether indexes could improve their execution performance.
 
 For each query, we analyzed:
@@ -220 +220 @@
 
 # After adding indexes, PostgreSQL still selected sequential scans for the main tables. The query performs monthly aggregation over most of the enrollment and quiz_attempt records, so the planner estimated that sequential scanning was cheaper than using indexes. The execution time increased from 87.215 ms to 111.731 ms, therefore these indexes did not improve this specific analytical query.
+
+**Overall Conclusion**
+
+Both analytical queries were tested using PostgreSQL EXPLAIN ANALYZE before and after index creation.
+
+Although indexes were added on the main JOIN and date columns, PostgreSQL continued to choose Sequential Scan operations for the largest tables.
+
+This behavior is expected for analytical reports that process a large portion of the available data through JOIN, GROUP BY, COUNT and AVG operations.
+
+The analysis demonstrates how PostgreSQL selects the most cost-effective execution plan and confirms that indexes do not necessarily improve every type of query.
 
 = Security and Protection Measures =