6 ms·

It's very true today. The problem discussed here is performance on complex queries (e.g. subqueries), and the query planner plays a huge role in that. The Postg

It's very true today. The problem discussed here is performance on complex queries (e.g. subqueries), and the query planner plays a huge role in that. The Postgres query planner has various issues. Here are two recent posts talking about planner issues: https://medium.com/@rbranson/10-things-i-hate-about-postgresql-20dbab8c2791 https://medium.com/@rbranson/10-things-i-hate-about-postgres... https://www.cybertec-postgresql.com/en/things-could-be-improved-postgresql/ https://www.cybertec-postgresql.com/en/things-could-be-impro... Also JIT compilation, while very nice and a step in the right direction, is very barebones at the moment, hardly achieving its potential. Here's a long todo list of what and how to make efficient use of JIT in postgres, by the main author of the feature. https://twitter.com/AndresFreundTec/status/1002589969616199680 https://twitter.com/AndresFreundTec/status/10025899696161996... Postgres release 12 did not add any JIT related improvements, and as far as I know no work has been done on it on 13 either.

ksec 6y ago
For someone not following closely, What are the reasons behind the lack of work on JIT since then?
- tibiahurried 6y ago
  > The problem discussed here is performance on complex queries This is the problem. In my experience, these complex queries exist because of either unnecessary super normalized schema or one schema to fit them all. Nowadays storage is so cheap that you can safely de-normalize the schema and have tables that fit your query model. If you have very complex queries chances are that you must take a closer look at your application design.
- ris 6y ago
  The traditional view that the bottleneck for query performance is overwhelmingly disk throughput, which has become slightly less true with the advent of SSDs.
thda 6y ago
> as far as I know no work has been done on it on 13 either. You should check the latest commitfest. Improvements are coming, at a steady pace.
- sbuttgereit 6y ago
  Are you sure? I just made a very casual search of the most recently completed commitfest and I saw one entry ("JIT expression evaluation improvements") marked as "Moved to next CF" and in the upcoming one the only item planned was the one that was moved. Maybe there's more there with less obvious names?
  - thda 6y ago
    I am. 13 release is planned in the 3rd quarter. The next commitfest is in july.

ksec 6y ago

For someone not following closely, What are the reasons behind the lack of work on JIT since then?

tibiahurried 6y ago
> The problem discussed here is performance on complex queries This is the problem. In my experience, these complex queries exist because of either unnecessary super normalized schema or one schema to fit them all. Nowadays storage is so cheap that you can safely de-normalize the schema and have tables that fit your query model. If you have very complex queries chances are that you must take a closer look at your application design.
ris 6y ago
The traditional view that the bottleneck for query performance is overwhelmingly disk throughput, which has become slightly less true with the advent of SSDs.

thda 6y ago

> as far as I know no work has been done on it on 13 either. You should check the latest commitfest. Improvements are coming, at a steady pace.

sbuttgereit 6y ago
Are you sure? I just made a very casual search of the most recently completed commitfest and I saw one entry ("JIT expression evaluation improvements") marked as "Moved to next CF" and in the upcoming one the only item planned was the one that was moved. Maybe there's more there with less obvious names?
- thda 6y ago
  I am. 13 release is planned in the 3rd quarter. The next commitfest is in july.