3 ms·
Yes, skip-index scans require custom sql now. I am also a bit annoyed by cache-like uses not being first-class. Unlogged tables get you far, temporary tables a
by hamilyon2 2y ago
Yes, skip-index scans require custom sql now.
I am also a bit annoyed by cache-like uses not being first-class. Unlogged tables get you far, temporary tables are nice, but still all this feels like a hurdle, awkward and not what you actually need.
- drtgh 2y ago> I am also a bit annoyed by cache-like uses not being first-class. Since what happened recently with Redis[1] the first thing I thought about was Postgre, but the performance[2] difference is too noticeable, so one have to look for other alternatives, and not very confident due thinking such alternatives may follow the same "Redi's attitude" ( ValKey, DragonflyDB, KeyDB, Kvrocks, MinIO, RabbitMQ, etc etc^2 ). It would be nice if these cache-like uses within Postgre had a tinny push. [1] https://news.ycombinator.com/item?id=42239607 https://news.ycombinator.com/item?id=42239607 [2] https://medium.com/redis-with-raphael-de-lio/can-postgres-replace-redis-as-a-cache-f6cba13386dc https://medium.com/redis-with-raphael-de-lio/can-postgres-re... XXXXX achieves a latency of 0.095 ms, which is approximately 85% faster than the 0.679 ms latency observed for Postgres’ unlogged table. It also handles a much higher request rate, with 892.857,12 requests per second compared to Postgres’ 15.946,02 transactions per second.