2 ms·

I don’t understand. It’s not like we don’t already have faster alternatives, don’t we have things like k and kdb that are many orders of magnitude faster even t

I don’t understand. It’s not like we don’t already have faster alternatives, don’t we have things like k and kdb that are many orders of magnitude faster even than this? We use Postgres because it’s fantastic at the scale and problems it solve, if you have an extremely critical system where raw speed is at the core of everything and you’re dealing with petascale then maybe you’re bringing a solution you like to a problem it doesn’t fit?

repsilat 3mo ago
Faster is better than slower. Postgres is amazing. When I use Sqlite I miss many of its upsides--better data migrations and better concurrency being two. But queries are not free, and sometimes are slower than I'd like even with the right indexes. And for OLAP-like queries like the one in TFA you might say "well, just don't use postgres for that," but wouldn't it be better if you could? If you could use one database instead of two, or use your favourite database in more places instead of reaching for a different tool?
- a34729t 3mo ago
  So why not take the approach all the fast olap systems are going and serve as the indexing and query layer and put storage at the object store level?
  - repsilat 3mo ago
    Maybe that's the right approach, hard to say. No great harm making this kind of improvement if it isn't the globally best architectural direction.
- hmokiguess 3mo ago
  > wouldn't it be better if you could? If you could use one database instead of two, or use your favourite database in more places instead of reaching for a different tool? No, I used to but not anymore. I do appreciate when solving the problem is enjoyable with a tool that brings in a good experience, but I try not to get attached these days. I get what you're saying though.
mhh__ 3mo ago
There should be a halfway point between kdb and postgres... So more seriously my thinking is that we should, on purely moral grounds strive to have things be fast and lean. How many years of human misery have been lost to waiting around for python programs for example because the team for years wanted to the interpreter to be simple
- hmokiguess 3mo ago
  I find your phrase contradicting in itself. You can't have your cake and eat it too. Where do you draw the line? Fast and lean means killing abstractions and DX. Look at Taalas burning the model weights into the wafer for example.

repsilat 3mo ago

Faster is better than slower. Postgres is amazing. When I use Sqlite I miss many of its upsides--better data migrations and better concurrency being two. But queries are not free, and sometimes are slower than I'd like even with the right indexes. And for OLAP-like queries like the one in TFA you might say "well, just don't use postgres for that," but wouldn't it be better if you could? If you could use one database instead of two, or use your favourite database in more places instead of reaching for a different tool?

a34729t 3mo ago
So why not take the approach all the fast olap systems are going and serve as the indexing and query layer and put storage at the object store level?
- repsilat 3mo ago
  Maybe that's the right approach, hard to say. No great harm making this kind of improvement if it isn't the globally best architectural direction.
hmokiguess 3mo ago
> wouldn't it be better if you could? If you could use one database instead of two, or use your favourite database in more places instead of reaching for a different tool? No, I used to but not anymore. I do appreciate when solving the problem is enjoyable with a tool that brings in a good experience, but I try not to get attached these days. I get what you're saying though.

mhh__ 3mo ago

There should be a halfway point between kdb and postgres... So more seriously my thinking is that we should, on purely moral grounds strive to have things be fast and lean. How many years of human misery have been lost to waiting around for python programs for example because the team for years wanted to the interpreter to be simple

hmokiguess 3mo ago
I find your phrase contradicting in itself. You can't have your cake and eat it too. Where do you draw the line? Fast and lean means killing abstractions and DX. Look at Taalas burning the model weights into the wafer for example.