rw-access

Joined 3 years ago

Karma

Submissions

Member since

Feb 21

Recent submissions

I have hundreds of queries like this in production (Go + Postgres + pgx), and don't have issues leveraging the right indexes. Make sure when using prepared statements, you have custom query plans per query for this via `SET plan_cache_mode = force_custom_plan`.

These optimizations are trivial for Postgres to make optimization/plan time, so there's no runtime hit. But as always, profile and double check. You're definitely right that assuming can get you in trouble.

I don't have experience with the other databases to speak to their quirks. But for my specific setup, I haven't had issues.

Comment · 2 years ago

The CLA best answers the questions in your first paragraph.

https://www.elastic.co/contributor-agreement

Comment · 3 years ago

Assuming the MxN claim was accurate, yeah. The author of this post wrote a prior one [1], challenging whether MxN was truly the problem LSP was solving. It's also a good read!

https://matklad.github.io/2022/04/25/why-lsp.html

Comment · 3 years ago

That's part of the protocol with a Document highlight request. Basically if you click on a symbol in the client, it'll send the server side request where it can find all references and mark which ones are read and which are write. The client will then highlight those references with one color for read, one for write, and one for other textual occurrences.

https://microsoft.github.io/language-server-protocol/specifi...

Full-text search engine with PostgreSQL (part 2): Postgres vs. Elasticsearch xata.io

110 rw-access 3 years ago 16 comments

rw-access

Recent submissions

Full-text search engine with PostgreSQL (part 2): Postgres vs. Elasticsearch x xata.io

Full-text search engine with PostgreSQL (part 2): Postgres vs. Elasticsearch xata.io