pg_plan_advsr
hypopg
| pg_plan_advsr | hypopg | |
|---|---|---|
| 1 | 6 | |
| 92 | 1,262 | |
| - | 13.3% | |
| 6.8 | 5.0 | |
| about 2 months ago | 13 days ago | |
| C | C | |
| - | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
pg_plan_advsr
-
Discussion: the feasubility of using open source hyperparameter optimization tools and SQLAlchemy to automatically tune database performance
Something along the lines of https://github.com/ossc-db/pg_plan_advsr sounds more promising.
hypopg
-
Show HN: PostgreSQL Index Advisor
It works particularly well with pg_stat_statements[0] which tracks execution statistics of all SQL statements executed on your Postgres database.
It leans heavily on HypoPG[1], an excellent extension to determine if PostgreSQL will use a given index without spending resources to create them.
[0] pg_stat_statements: https://www.postgresql.org/docs/current/pgstatstatements.htm...
[1] https://github.com/HypoPG/hypopg
-
YugabyteDB hypopg: hypothetical indexes
This is an introduction to the hypopg PostgreSQL extension for YugabyteDB 2.15.3.0. Hypopg allows the creation of hypothetical indexes, so indexes that do not really exist. This means this allows you to see what an index would do if it were created, without it actually being created, and therefore not influencing anything on the database. YugabyteDB 2.15.3.0 is a preview version of the YugabyteDB database.
- The SQLite Index Suggester
-
Why Can't Database Tables Index Themselves?
There's a lot of good ecosystem stuff around this:
https://github.com/HypoPG/hypopg
HypoPG is a PostgreSQL extension adding support for hypothetical indexes.
An hypothetical -- or virtual -- index is an index that doesn't really exists, and thus doesn't cost CPU, disk or any resource to create. They're useful to know if specific indexes can increase performance for problematic queries, since you can know if PostgreSQL will use these indexes or not without having to spend resources to create them.
With one approach to using it here: https://www.percona.com/blog/2019/07/22/automatic-index-reco...
- Postgres Indexes for Newbies
- PostgreSQL Explain Output Explained
What are some alternatives?
optuna - A hyperparameter optimization framework
pev2 - Postgres Explain Visualizer 2
hyperopt - Distributed Asynchronous Hyperparameter Optimization in Python
ruby-pg - A PostgreSQL client library for Ruby
orafce - The "orafce" project implements in Postgres some of the functions from the Oracle database that are missing (or behaving differently).Those functions were verified on Oracle 10g, and the module is useful for production work.
sqlite-wf - Simple visual ETL tool
pg_show_plans - Show query plans of all currently running SQL statements
libfirm - graph based intermediate representation and backend for optimising compilers
idx - maps, sets and vectors with on-demand secondary indexes.
plpgsql_check - plpgsql_check is a linter tool (does source code static analyze) for the PostgreSQL language plpgsql (the native language for PostgreSQL store procedures).
postgresql-unit - SI Units for PostgreSQL