Vadim_samokhin

Just in case, there is a btree_gin extension which can be used in queries combining gin-indexable column and btree-indexable column. It doesn’t solve top-K ordering problem though.

I think test pyramid is a great idea, in theory. In practice, having lots of unit tests with mocked dependencies doesn’t make me sure that everything works as it should. Thus, I use real database in my unit tests. There, I test serialization errors, authentication problems, network issues, etc. All the real problems which can occur in real life. Leaving these scenarios for integration tests layer will turn a test pyramid to a test diamond.

And what was the rationale behind mocking a database in the first place, speed? Disable synchronous wal writes, or run your postgres instance in ram. Your test suite execution speed will skyrocket.

Whoa, the first step towards a garbage collector? :)

I think postgres really excelled at this pattern. As well as other databases implementing a query planner.

> And yes, absolutely _never_ make it your primary key.

If I dont have lots of range queries, why not then? Only because of bloating (I think fragmentation is a more precise term here)?