saisrirampur

8 ms·

91.
by saisrirampur 4mo ago
I know I know. Some people have loved it as it captures what it does (peering dbs) and some haven't because of the exact reason you called out. So we get it! :)
92.
Ten years of ClickHouse in open source(clickhouse.com)
329 points by saisrirampur 4mo ago|101 comments
93.
Debugging Postgres Autovacuum(citusdata.com)
2 points by saisrirampur 4mo ago|0 comments
94.
by saisrirampur 4mo ago
Separately, this is one of the Postgres autovacuum tuning blog that I've ever read. Have seen it work across many customers and it is also simple to decipher and implement. https://www.citusdata.com/blog/2022/
95.
by saisrirampur 4mo ago
(Most) CRUD/OLTP applications don't delete data by timestamp; they delete by primary key. For those workloads, DROP TABLE (or dropping a partition) isn't a palatable option. The entire premise here is really about time-series
96.
by saisrirampur 4mo ago
Partially true but too much of a blanket statement and clickbaity. DELETE with well-tuned autovacuum works pretty well. Have seen it work at TBs scale with no hicuups. If DELETEs are large, we used to recommend customers to follow that with
97.
PostgresBench: A Reproducible Benchmark for Postgres(clickhouse.com)
2 points by saisrirampur 5mo ago|0 comments
98.
by saisrirampur 5mo ago
It depends on the use case. For real-time, customer-facing analytics, ClickHouse’s MergeTree engine is a natural fit, so a Postgres → ClickHouse CDC setup with low latencies (single-digit seconds) is better. Replication to Iceberg/S3 i
99.
ClickHouse launched a native Postgres managed service(clickhouse.com)
2 points by saisrirampur 5mo ago|0 comments
100.
Postgres FDW: Pushdown is a negotiation(clickhouse.com)
1 points by saisrirampur 5mo ago|0 comments
101.
PostgresBench: A Reproducible Benchmark for Postgres Services(clickhouse.com)
1 points by saisrirampur 5mo ago|0 comments
102.
PostgresBench: A Reproducible Benchmark for Postgres Services(clickhouse.com)
4 points by saisrirampur 6mo ago|0 comments
103.
PostgresBench: A Reproducible Benchmark for Postgres Services(clickhouse.com)
3 points by saisrirampur 7mo ago|1 comments
104.
Pg_stat_ch: Deep Postgres observability through ClickHouse(github.com)
2 points by saisrirampur 7mo ago|0 comments
105.
Pg_stat_ch: Postgres extension that exports every metric to ClickHouse(github.com)
2 points by saisrirampur 7mo ago|0 comments
106.
Faster Data Migrations for Postgres(clickhouse.com)
1 points by saisrirampur 7mo ago|0 comments
107.
by saisrirampur 8mo ago
Great progress, guys! It’s impressive to see all the enhancements - more types, more aggregate functions, cross-node DML, resharding, and reliability-focused connection pooling and more. Very cool! These were really hard problems and took m
108.
Pg_ClickHouse: Fastest Postgres Extension on ClickBench(clickhouse.com)
1 points by saisrirampur 8mo ago|0 comments
109.
Pg_stat_ch: Observe Postgres from ClickHouse(clickhouse.com)
1 points by saisrirampur 8mo ago|0 comments
110.
AI-powered migrations from Postgres to ClickHouse(clickhouse.com)
3 points by saisrirampur 8mo ago|0 comments
111.
Pg_stat_ch: Postgres extension to ship every PG metric to ClickHouse(clickhouse.com)
2 points by saisrirampur 8mo ago|0 comments
112.
Pg_stat_ch: A PostgreSQL extension that exports every metric to ClickHouse(clickhouse.com)
2 points by saisrirampur 8mo ago|0 comments
113.
Show HN: Pg_stat_ch, a Postgres extension to export every metric to ClickHouse(github.com)
4 points by saisrirampur 8mo ago|0 comments
114.
Show HN: An open-source starter kit for developing with Postgres and ClickHouse(github.com)
1 points by saisrirampur 8mo ago|0 comments
115.
by saisrirampur 8mo ago
Ack, makes sense. When making public posts that reach a large audience, it’s better to be clear with the messaging rather than risk it being blurry for even a subset of the audience, especially if that could lead to misguidance and affect t
116.
by saisrirampur 9mo ago
Ack, agreed. But there’s a better way to communicate than making blanket statements like “just use Postgres.” For example, you could say “Postgres is the default database,” etc. Don’t get me wrong—I’m a huge huge fan of Postgres. I’ve worke
117.
by saisrirampur 9mo ago
That wasn’t my intention though to mention my workplace multiple times for the sake of PR. Try to avoid being that, atleast on hn. :)
118.
by saisrirampur 9mo ago
Agree to disagree here. I see a world where developers need to think about (reasonable) scale from day one, or at least very early. We’ve been seeing this play out at ClickHouse - the need for purpose-built OLAP is reducing from years to mo
119.
by saisrirampur 9mo ago
I personally see a difference between “just use Postgres” and “make Postgres your default choice.” The latter leaves room to evaluate alternatives when the workload calls for it, while the former does not. When that nuance gets lost, it can
120.
by saisrirampur 9mo ago
I’m a huge Postgres fan. That said, I don’t agree with the blanket advice of “just use Postgres.” That stance often comes from folks who haven’t been exposed enough to (newer) purpose-built technologies and the tremendous value they can cre

More ›