Top
Best
New

Posted by poly2it 19 hours ago

Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD(malisper.me)
266 points | 127 commentspage 3
borplk 12 hours ago|
I'll take the 300x slower non-vibe-coded pg, thanks!
refulgentis 11 hours ago|
They disabled Postgres parallelism to benchmark too. Sigh.
malisper 11 hours ago||
We disabled parallelism in the blog post for demonstration purposes. The 300x slower refers to the clickbench numbers[0] where parallelism is enabled

[0] https://benchmark.clickhouse.com/#system=+liH|pgrs|gQ&type=-...

refulgentis 11 hours ago||
Who is "we"?
postgresperf 8 hours ago|||
The pgrust team asked me to look at their results on a review system, and I confirmed the ClickBench speedup there. Regular PostgreSQL is really terrible at some of these queries. Unfortunately fixing that is hard to do in core itself because columnar storage lives outside of the main tree, and some optimization problems only show up when layered on columnar.
malisper 6 hours ago||
^For context, this is Greg Smith, the author of Postgres 9.0 High Performance[0]. That book was my first introduction to Postgres

[0] https://www.amazon.com/dp/184951030X

malisper 11 hours ago||||
Me and Jason, the two people working on the project
booksock 10 hours ago|||
hi
xyzzy_plugh 14 hours ago||
[dead]
Natalia724 13 hours ago||
[dead]
wkoszek 5 hours ago|
I'm really happy seeing this project. Not sure if this helps you gain $$$ customers, but stupid thing that turns out very difficult in PG is making this fast:

SELECT COUNT(*) FROM large_text_db WHERE X

Where X is something that must be matched exactly. X can be FTS query on FTS-indexed table, but the way COUNT() works in PG is that it's impossible to make it fast. Over large tables, lets say 1B+ rows, it can be very very slow.

Example use case is: searching through a hospital DB of reports that have "pancreatic cancer" in them. This is trivial in SQLite, but in PG it's hard.