Chinese, Japanese, Korean etc.. don’t work like this either.

However, even though the approach is “old fashioned” it’s still widely used for English. I’m not sure there is a universal approach that semantic search could use that would be both fast and accurate?

At the end of the day people choose a tokenizer that matches their language.

I will update the article to make all this clearer though!

100%, maybe we should do a follow up on other types of tokenization.

Hello HN, author here. It seems like everyone is talking about 'hybrid search' (lexical/BM25 + semantic/vector) these days, so I wanted to show how it's possible (and fully customizable) using reciprocal rank fusion in SQL.

The original title of this post was "When Tokenization Becomes Token", but nobody got it.

I'm curious, after reading this article how many people can tell me why that title would have been great?

(also I'd love feedback on the interactive components, I think they came out well!)

hello. it would be great because it celebrates the total destruction of the search capabilities of the tool, just like the article does.

Author here — you beat me to it!

Hi everyone A lot of you will probably see the title of this post and immediately think “of course, just use the right tool for the job.”

But for those who don’t … here's a thing for you.

I’d really love to hear from both sides:

- Folks who’ve been burned by using Elastic as a primary datastore.

- Folks who haven’t — and can make the case for why it works just fine. (I know some of you are out there!)

Not the case!

Then why reference the "Agentic Era" in the title?

Tiger here, let's go!

Hi HN! I've been benchmarking again, this time looking at all the permutations of COPY and INSERT in Postgres.

Let me know what you think.

Hi HN! If you're interested in PostgreSQL or database performance here's a short benchmark I did looking into the seemingly magical performance gain you can get by INSERTing unnested arrays rather than VALUES tuples in Postgres.

Let me know if you have any questions or suggestions for next articles.

Interesting, is there a reason why Postgres wouldn't just apply the shared query planning to INSERT...VALUES as well, it seems like almost a no-brainer to speed up all queries. Or is this more related to how the parser works with the values?

Hi HN!

I wrote this article comparing TimescaleDB's SkipScan feature to vanilla Postgres performance for DISTINCT queries (get me the last row for all IDs) while a 200K rows per second ingest was happening.

I'm going to be writing more of these smaller performance pieces (sometimes Timescale related, sometimes Postgres related) - I'd love to hear some suggestions (especially around PG performance) from the HN community