-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Moving to Elastic Search was a mistake #1
Comments
(Note: You should not use |
This also significantly helps the (platform, board, thread) case: Benchmark: 3.395ms to 0.231ms
|
This is all extremely promising! I'm excited to include this all in the codebase. I was initially hesitant about including raw SQL as it seems un Django-ish (Djangoistic?) but after looking through documentation it seems there is currently no way to create managed materialized views natively in Django. Getting the views to interface with Django is an additional step, but it looks like a pretty straightforward one. A Django model needs to be created for the view with metadata specifying So it seems like a reasonable next step would be to create perhaps a new management command for the project which executes a raw SQL query dropping and then creating all of the views needed, then create corresponding Django models for each new view. As for new indices, there is a native way to create them on models and it appears btree is the default. So going forward I'd like to go with this rule of thumb: It's okay to use raw SQL for creating views and indices, but all actual querying of records should be done through the ORM with I'll do my best to implement the needed changes with those restrictions in mind! |
That sounds reasonable, although some of my other queries may be too insane to easily map to the ORM, esp #3's. |
…in general, but at least for pagination/non-full text lookups (and even for these there are GIN and GiST indexes).
In Discord I was told it was moved to due to problems with slow lookups.
I have solved this.
While originally I tried a bit of an insane solution with hash indices, real world testing showed that a fuckload of btree indices narrowly beats that.
posts_post_fk_view
Indices
Benchmark: From 4800ms to 4ms
The text was updated successfully, but these errors were encountered: