11 ms·
Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD
- myshapeprotocol 1mo ago[flagged]
- cognitiveinline 1mo agopgrust seems to have good momentum. AGPL is an odd license for a non web project. Postgres is MIT-like, and that drove it's adoption. Have pgrust folks reconsidered this? Else, IMO we can have an independant rust port of pgrust, which can be MIT, which will garner more attention.
- ognarb 1mo ago2 commits in the repo both generated by claude. This is AI slop, I wonder where you see good momentum?
- esafak 1mo ago4K stargazers in a week.
- saberience 1mo agoStars have long ceased to have any meaning since they can be both automated and bought. Just look at Garry Tans ai slop prompts which got 60k stars in a few weeks.
- Whitespace 1mo agomain indeed has two commits, but it clearly states the location of the rest of the commits, so I wouldn't be critical of main itself. hey claude, do a breakthrough You can find the actual git history at the v0.2 github tag. Co-Authored-By: Fable <noreply@anthropic.com> Now we see https://github.com/malisper/pgrust/tree/v0.2 https://github.com/malisper/pgrust/tree/v0.2 has almost 6000 commits in it, with the very first one on 2026-07-02. That's a lot of token momentum! It's easy to claim AI slop nowadays, but you should still mistrust-but-verify.
- f311a 1mo agoWhat's the reason for it? Does not make a lot of sense to keep all the commits elsewhere
- malisper 1mo agoIt's a reference to the prompt that found a counterexample to the Dinitz-Garg-Goemans conjecture > "do a breakthrough and find a structured counterexample"
- refulgentis 1mo agoWhat do we mean by "easy to claim"? It is written by AI. The 6000 commits are by Claude.
- busterarm 1mo agoEverything around Rust is political, so the license choices are also about political statement.
- johnsonjo 1mo agoMost official Rust projects are dual MIT/Apache licensed by convention [1] (and most Rust libraries from third parties I've seen that are open source MIT follow the MIT/Apache dual license), so seems like this library shouldn't just be AGPL for a typical political choice of a Rustacean? [1]: https://rust-lang.org/policies/licenses/ https://rust-lang.org/policies/licenses/
- busterarm 1mo agoofficial projects are usually run by sensible people who want to do things and aren't leading with ideology. We're literally talking about an "X but in Rust" project already...
- appplication 1mo agoOh bummer. I was really excited about pgrust but AGPL is a dealbreaker. Not for me personally, but it will never see wide adoption because it’s a banned license in most corporate environments. Lack of path to wide adoption means it’s dead in the water. It’s weird because those who actually care about optimized pg gains are most likely large corporate customers. Why make a product targeting them and license it in such a way they’ll never use it? This also hard blocks upstreaming any beneficial features into core Postgres.
- karlmush 1mo agoAGPL seems like the right choice to me. I’m tired of companies like PlanetScale taking PostgreSQL, building a business on top of it, and then acting like PostgreSQL is theirs to control.
- samlambert 1mo agowe have not once claimed postgres is under our control. i don't think you understand how open source works but thats ok.
- guenthert 1mo agoIf it is indeed 300* faster, I'm sure more rational corporations will rethink their license policy or be left in the dust.
- xyzzy_plugh 1mo agoThey could simply spend a few months and a few million tokens and get their own port, no? I doubt even 30000x faster would prompt a policy change.
- superb_dev 1mo agoAre you suggesting the AI just rewrites the whole thing under a different license? There’s no way that’s not more dicey than the AGPL license.
- malisper 1mo agoAuthor here. At least for databases, AGPL (or stricter) has become standard. The issue is it's so easy for megacorps (Amazon, Google, etc) to take a permissively licensed product and monetize it at the expense of the original standard. For instance, Mongo, Cockroach, and Materialize have all gone source available. We picked AGPL because it's the best balance between open source and prevents Amazon from just repackaging it and selling it. If AGPL is an issue for anyone, we would be happy to dual-license under a commercial license.
- cognitiveinline 1mo agoSure, that's your prerogative, and kudos for not talking up open source. I'm not amazon size so can't use it, and AGPL is a no go for DB, don't want to be forced to open source my app because I use this! Will await a MIT based fork myself.
- jnwatson 1mo agoWhy would AGPL force you to open source your app? Unless you literally compile your app with pgrust by modifying the pgrust source code, you're safe. Clients aren't bound by the AGPL because they aren't derived works.
- xyzzy_plugh 1mo agoHere we go again. AGPL is untested in courts. There is no definitive definition of what could be considered within the blast radius such that it would require AGPL licensing. There's a reason AGPL is banned at Google and most sane companies. It's simply too dangerous. You can't simply say "clients aren't bound" because it depends. I'd rather see the BSL used here to be perfectly honest. At least it's simple.
- jnwatson 1mo agoWhile the AGPL is untested, what a derived work is is less so. It is entirely outside the bounds of the intentions of the authors of the AGPL for clients to be infected.
- wrs 1mo agoGood news, we now know up front what an independent port would cost, and it’s not much. So no reason AWS, Google, and friends couldn’t bang out their own port if they want, binary-compatible with this one. What we don’t know for sure is whether there is any copyright for LLM-generated code. The license might be irrelevant!
- kopirgan 1mo agoCan some of these optimization get back propagated to Postgres?
- malisper 1mo agoAuthor here. Let me know if you have any questions about the post or about pgrust. Let me take a shot at answering what I think will be the most common question: how can I trust pgrust? Our #1 priority right now is correctness. Over the past two weeks, I've done a mix of formal verification and differential fuzz testing. We've been able to prove over 1000 user facing functions have the exact same logic in both pgrust and postgres (see the proofs directory if you're curious). For cases where formal verification is not easy, we've taken the c implementation of a function and the rust implementation of a function and ran millions of inputs through each of them and confirmed they gave the same results every time. We've only covered about 15% of the surface area so far, but in the process, we've discovered ~100 bugs in pgrust and ~20 bugs in Postgres itself. My favorite postgres bug we found is this one[0]. Postgres has a quadtree implementation. Due to floating point rounding, it was possible for a point to be neither above, nor below, nor even with the center point of the quadtree. We've also entered engagements with Antithesis[1] to do Jepsen style fault testing and Aretta[2] to do more serious formal verification. If you want to support the project, the easiest way is to give us a star on GitHub[3] [0] https://www.postgresql.org/message-id/19597-39c532e61d78dff6%40postgresql.org https://www.postgresql.org/message-id/19597-39c532e61d78dff6... [1] https://antithesis.com/ https://antithesis.com/ [2] https://aretta.ai/ https://aretta.ai/ [3] https://github.com/malisper/pgrust https://github.com/malisper/pgrust
- doctorpangloss 1mo ago“Show me the prompt.”
- jnwatson 1mo agoThe floating point comparison bug is nightmare fuel. I could look at that for years and never spot the mistake.
- bee_rider 1mo agoOn the bright side it could probably run for years without hitting the mistake as well. But it is nice to get it out of there.
- 1mo ago
- xyzzy_plugh 1mo ago[dead]
- Lucasoato 1mo agoI’m curious to see how this compares to pgColumnar or other OLAP extensions.
- malisper 1mo agoAt least in terms of speed, we're much faster on clickbench: https://benchmark.clickhouse.com/#system=+_b|pnc|pgrs|gQ|saB&type=-&machine=+g4e&cluster_size=-&opensource=-&hardware=+c&tuned=+n&metric=combined&queries=- https://benchmark.clickhouse.com/#system=+_b|pnc|pgrs|gQ|saB...
- rastignack 1mo agoI would be interested about a more detailed architecture overview of the io scheduler (like this: https://www.scylladb.com/2021/04/06/scyllas-new-io-scheduler/ https://www.scylladb.com/2021/04/06/scyllas-new-io-scheduler...) and the thread scheduler. PostgreSQL has historically been bad at managing the noisy neighbor problem, but with thread pools, and io priorities, it can be solved. Has this been tackled here ?
- malisper 1mo agoI'll need to write up how the scheduler works at some point, but it's heavily based on these papers[0][1]. It solves two different problems. First, it lets us throttle resource-intensive queries. Second, it enables work stealing. If you have idle cores on your machine, we'll assign those cores to running queries to help speed them up. That means if you have an over-provisioned machine, we'll make use of the extra capacity to speed your queries up. [0] https://15721.courses.cs.cmu.edu/spring2016/papers/p743-leis.pdf https://15721.courses.cs.cmu.edu/spring2016/papers/p743-leis... [1] https://db.in.tum.de/~kohn/papers/query-scheduling-sigmod21.pdf https://db.in.tum.de/~kohn/papers/query-scheduling-sigmod21....
- rastignack 1mo agoInteresting. It would need some work to handle all the workloads I’ve faced where you have two applications with different priorities (ie oltp or grid workloads and analytics). In those cases you want to make sure that BI users do not interrupt the transaction processing by assigning them a set of cores, a priority, and work mem limits for example. Looks doable without major changes.
- malisper 1mo agoWe don't expose the priorities right now, but we have the priorities decay over time. That way faster queries get prioritized over long running queries. That should achieve the behavior you're looking for.
- 1mo ago
- Natalia724 1mo ago[dead]
- AsyncBanana 1mo agoYou have no idea how long I have been waiting for adaptive planning. One of my biggest annoyances with the Postgres core team has been their reluctance to implement any sort of adaptive planning despite it, at this point, being a well-established technique that has been implemented in multiple production databases. I hope this, at the very least, proves the viability of this model outside of academic/niche contexts.
- KolmogorovComp 1mo agoThanks to the authors for choosing a license that respect users freedom, on top of being an awesome technical project.
- jjice 1mo agoWhile I do like pgrust's license, I do feel like it's kind of wrong to port in such a direct way and change the license. I guess this isn't a fork, but it kind of is? It looks like according to this post [0], they did a Claude Fable + Opus re-write. I know that legally this is seemingly a valid way to do things and avoid copyright, but it feels wrong to me. I don't even necessarily think that my feelings are correct, but standing on the backs of giants and using an LLM to "reimplement" the code (not a clean room implementation) feels like it's it _shouldn't_ be a valid way to avoid copyright or allow for license changes. Now, I don't know how MIT -> AGPL re-licensing specifics work, but still. [0] https://malisper.me/postgres-in-rust-regression-suite/ https://malisper.me/postgres-in-rust-regression-suite/
- nz 1mo agoMy understanding is that they used c2rust, and then told the LLM/Agents to make the code more idiomatic rust, while also using the PG test suite as a feedback mechanism. This is almost certainly a derived work (and thus a fork, and should thus have the original license and copyright preserved). For example, if I compiled PG into x86-64 assembly, and then decompiled it into C (via, say, IDA), and then polished that decompiled C code into very readable C code, it is still a derived work. For some reason, people think that if you include an LLM or Agent, copyright can be ignored, and plagiarism is now no longer possible. It is similar to the crypto-folks thinking that if you use crypto, you no longer have to pay taxes, because the internet/computers make all inconvenient realities go away. Honestly, such flagrant and arrogant copyright violations make it hard for me to take the project seriously, because it seems like a desperate stunt for attention (which itself may be a solid business move, but that is besides the point). Put differently, if one were to fork pgrust, strip away the new license and copyright, and restore the original PG license and copyright (while also adding malisper+team to that copyright), they would face no legal consequences at all. In fact, they would probably be a less legal risk than the pgrust team.
- sgt 1mo agoCool project but .. reality is that people will generally not choose pgrust over Postgres, even 5-10 years from now. The problem is not that it may be technically superior and faster by then, it's that it's not built by the trusted Postgres team. There's a lot more to trust than development velocity or performance. It's also about the longevity and continuity of a critical piece of technology.
- yieldcrv 1mo agoTheir ai agents will if we keep writing about it Project managers and Human Resources rolling out overengineered projects will outnumber current software engineers 10 to 1
- sgt 1mo agoThat's a pretty gloomy view
- yieldcrv 1mo agoThey will be software engineers or the people doing the software work And different people will be doing product management and HR all because today’s software engineers don’t want to babysit AI agents and choose antiquated libraries so that their resume said they'd been using a popular framework for a couple years Nobody else is playing that outdated game, its just a rotation
- sgt 1mo agoWhat are we going to do about this?
- yieldcrv 1mo agothis thread is talking about using a 300x faster library and theorizing a resistance to devs using it just use the faster library? leverage compute resources more effectively and justify value to an organization better than the next person otherwise, what needs to be done? I don’t see a problem with any of this aside from organizations risking less experienced people doing less efficient things in other parts of the stack
- refulgentis 1mo agoThe project has 2 commits. 2. Commit #1's message is "hey claude, do a breakthrough" from a week ago and is 1.5M lines. Commit #2 is "blog post" from 4 days ago. My head is spinning. I don't mind AI stuff or AI enabled stuff but there's gotta be some bar for ending up on HN, and also personal accountability: the lack of humility and honesty sets a new low for me. There is no "we" who "released pgrust 0.2". It's one person cosplaying a serious engineering team doing a mountain of work. The bus factor is 1, and its one you can't trust on the basics. ex. the first 1/3 of the blog post is bloviating about how a rust for loop is faster at summing 500M numbers on the heap than loading the numbers from a table and summing them. It leaves me in quite some anguish. This site kept me well-informed and growing for 16 years. It is no longer reliable for that as long as things like this can be the #1 post with 60 comments, with the author here, and no one mentioned any of this.
- wffurr 1mo agoThe second line of commit #2's message is "You can find the actual git history at the v0.2 github tag." which in turn has almost 6000 commits. I think it's a weird way to handle git history versus squashing feature branches into single commits, but it's not just one Claude session slapped up on GitHub. The OP also has a post above about their exhaustive testing which has uncovered a goodly number of bugs in Postgres itself, too. I think it's fair to say they're putting in a good amount of work on this.
- refulgentis 1mo agoI cloned it. The 6000 commits are the problem, not the defense. 5,940 commits, one author, 29 days. 5,067 of them, 85%, have a `Co-Authored-By: Claude` trailer. Busiest day is 1,393 commits, running 60-105/hour for ~20 hours straight. Commit messages reference .claude/skills/fleet/ and agent worktree "lanes". That's an unattended agent fleet committing once a minute around the clock. Commit count used to mean review time. Here it means GPU time. Also: the v0.2 tag shares no common ancestor with main. git merge-base fails. "The actual git history" is an orphan branch grafted in after the fact. And the testing rigor we're crediting them for should be weighed against the headline claim: 300x faster than Postgres, ahead of ClickHouse: fastest analytical DB on earth, one guy, one month. Most damning: the Postgres baseline ran with *max_parallel_workers_per_gather = 0*. Parallel engine vs. deliberately-hobbled single-core Postgres, headline says 300x. Using AI is fine. But "look how many commits" is precisely the signal this workflow is built to fake.
- borplk 1mo agoI'll take the 300x slower non-vibe-coded pg, thanks!
- refulgentis 1mo agoThey disabled Postgres parallelism to benchmark too. Sigh.
- malisper 1mo agoWe 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=-&machine=-6t|ca2|6ax|g4e|6ale|3al&cluster_size=-&opensource=-&hardware=+c&tuned=+n&metric=combined&queries=- https://benchmark.clickhouse.com/#system=+liH|pgrs|gQ&type=-...
- refulgentis 1mo agoWho is "we"?
- malisper 1mo agoMe and Jason, the two people working on the project
- booksock 1mo agohi
- postgresperf 1mo agoThe 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.
- wiradikusuma 1mo agoI think in addition to making it faster, it would be useful if it could be made "leaner," e.g. can run better on lower-spec hardware than PG.
- claytonjy 1mo agodoes one not imply the other? if it can run faster in the same hardware, it should also run as fast on lower spec hardware
- wiradikusuma 1mo agoIf I'm not mistaken ClickHouse's min spec is quite steep.
- Tuna-Fish 1mo agoThat is not a given. A database server can run faster on better hardware because it more effectively and aggressively caches things in memory, which can hurt it on lower-spec systems. Or it can better utilize SIMD instructions that are not present on the low end. Or it is more effective at utilizing more threads, but is slower when run at a low threadcount, etc etc etc.
- smolder 1mo agoNo, it doesn't. Different algorithms can vary pretty wildly in performance based on the design of the hardware they run on. For instance cache sizes can make one implementation of a sort on a certain sized dataset faster or slower than another. You can have a theoretically fast algorithm that just isn't as cache efficient as a theoretically slower one in big-O terms. All levels of the memory hierarchy as well as storage have specific bandwidths and latencies that inform the real world performance results. Parallelism is another issue. Many cores can do work very fast when you're careful about how you split up work between them, taking into consideration the synchronization latency and individual cache sizes and so on. The best approach for doing work on 64 cores can be dramatically different from what works best on 1 or even 2.
- ZiiS 1mo agoSurly AI could also write a clearer headline. For the millions running it in production for decades, using a great echosystem of help support, books, consultants, and managed hosting providers; the is a noteworthy difference between the official release and a partially compatable rewrite.
- Seattle3503 1mo agopgrust looks interesting. Could it be used as a library by someone who wants a new DB for each integration test in their Rust test suite?
- malisper 1mo agoOne of the new features we recently built is "test mode". This brings cloning a template db from 100ms down to <10ms making it much better for tests. If you're interested in trying it out, please reach out to me at malis@pgrust.com
- saberience 1mo agoThere is no “we” built it. You’re cosplaying as someone who could build a database. In reality you yourself could never build Postgres or Redis or any other database. You’re not skilled enough or knowledgeable enough and you’re not willing to put the time in so you’ve simple vibe copied Postgres. Why would anyone ever trust you or this project?
- malisper 1mo ago> You’re cosplaying as someone who could build a database. > In reality you yourself could never build Postgres or Redis or any other database. > You’re not skilled enough or knowledgeable enough and you’re not willing to put the time in so you’ve simple vibe copied Postgres. What makes you think these things? I've been writing about the Postgres internals and giving talks about Postgres for a decade and have managed a Postgres cluster as big as 1PB of data
- huahaiy 1mo agoWriting about Postgres internals and managing a Postgres cluster is the extent of your database expertise? You are not self aware enough to know that doesn’t earn any trust?
- luciana1u 1mo ago[flagged]
- patkepa 1mo agoQuestion, does having it in pure rust, opens possibility of embedding pgrust directly into binary, making it an alternative to SQLite/turso?
- malisper 1mo agoIt absolutely can be embedded. The bigger enabler is replacing the process-per-connection model with a thread-per-connection model. Projects like pglite[0] had to give up concurrency because of it. We also support compiling to wasm so you can embed it in the browser too, which is what powers pgrust.com [0] https://github.com/electric-sql/pglite https://github.com/electric-sql/pglite [1] https://pgrust.com/ https://pgrust.com/
- wkoszek 1mo agoI'd help with testing if you helped them add this. I'd be interested in this.
- ComputerGuru 1mo agoLook into tursodb for this.
- sunzhousz 1mo agoI am very disappointed to see the direction: It is moving from a "interesting attempt to recreate system software" to "building flashy but useless demo" Everyone who knows a bit about databases knows the difference between execution models and what kind of optimization it brings.
- malisper 1mo ago> I am very disappointed to see the direction: It is moving from a "interesting attempt to recreate system software" to "building flashy but useless demo" What makes you say this is a useless demo? I can't count the number of people who've struggled to do analytics inside of Postgres. Almost always they end up setting up a separate system such as Clickhouse and replicating the data between the two systems. Now they can have one system that's Postgres-compatible, and it's faster than either of the original systems. > Everyone who knows a bit about databases knows the difference between execution models and what kind of optimization it brings. In our last post[0], when we mentioned we were getting close to Clickhouse level performance (now faster than Clickhouse), we were met with disbelief. This post is meant to explain part of how we closed the 300x gap between Postgres and Clickhouse. The execution model being 10x of it. [0] https://news.ycombinator.com/item?id=48841676 https://news.ycombinator.com/item?id=48841676
- nullpoint420 1mo agoI just deployed this to production to replace our self-hosted Postgres - and we’re experiencing corruption. Can you help us out?
- malisper 1mo agoYes. Email me and Jason at malis@pgrust.com and jason@pgrust.com
- nullpoint420 1mo agoWow ok fair enough. Sorry to put you through a fire drill but I wanted to see if there would be support or not. I stand corrected, there is. Wishing you the best of luck here.
- 3dedb728-3f77 1mo agoSo one trick you can do is make a ramfs/tmpfs and start Postgres on it. You need a server with enough ram to fit it all. But it kind of make the database fly.
- lossolo 1mo agoOr you can also just place one or more tables on tmpfs, we are doing that in production.
- shdnx 1mo agoYou can certainly do that, but it'll perform much worse than properly tuning your Postgresql to take advantage of requiring no durability and having lots of RAM. Source: I do this kind of thing for a living.
- jiggawatts 1mo agoBatch mode execution has been in Microsoft SQL Server for a while and just recently gained AVX-512 support. I’ve done some experiments replacing spatial SQL queries with custom vectorised batch mode code in C# and the speed up was astonishing. The people dubious about these claims have no idea what their computers are really capable of.
- up2isomorphism 1mo ago300x if it is true you will be just busy dealing with you customers rather than pitching here. Also since it is a vibe coded project, if you are really that good , you should even need to related yourself with Postgres. Who will want related itself to something that is 300x slower than itself?
- wkoszek 1mo agoYou use stability of PostgreSQL to open a pitch. Also most people use PostgreSQL because someone out there was a fan, proponent and champion of Postgres. Otherwise they'd be on MySQL or Oracle. And your sales folks would call and say: "No need to change anything, we still run PostgreSQL, and ours is just called pgrust, but it's N times as fast".
- wkoszek 1mo agoI'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.
- deleted 1mo ago[deleted]
- hmokiguess 1mo agoI 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 1mo agoFaster 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?
- hmokiguess 1mo 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.
- a34729t 1mo agoSo 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 1mo agoMaybe 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.
- deleted 1mo ago[deleted]
- Blazara 1mo agoI don't understand the use case. I've never seen why Postgres is better than anything else if I'm honest. Even if it is much, much faster, database transactions aren't what slow things down if written well in web applications.
- mindwok 1mo agoIt’s not just speed, it’s also the rich feature set. Trigram search, JSONB, transactions, GIN indexes, full text search - not many databases combine them all into a Swiss Army knife like Postgres does.
- NautilusWave 1mo agoReading about the batch optimization, I suspect there'll be trouble ahead for implementing window functions, unless those details were dropped for simplicity.
- malisper 1mo agoHow so? Window functions work exactly the same way. Postgres processes them one row at a time, and you can batch them the same way as you would with sum. Window functions do make parallel queries more difficult, but that's a different story.
- NautilusWave 1mo agoI guess regardless of if the calculations are batched or not, all the rows would have to be processed before the window function results could be determined.
- mdkdog 1mo agowanted to test this but no joy. "ERROR: convert_string_datum (selfuncs.c): pg_strxfrm leg; C-collation lane only" "thread 'pg:backend:1572' (11650) panicked at crates/backend/optimizer/plan/planner/src/selfuncs.rs:966:9:" i would say is not ready yet.
- malisper 1mo agoCan you file an issue? We know there are bugs and the work we're doing with formal verification and fuzz testing is to go through all the code and make sure all of it behaves identically to Postgres
- malisper 1mo agoWe've fixed the issue on our development branch. We've only been working with the default collation so when you try a different one it causes an issue
- k_bx 1mo agoWe went this path: pg -> peerdb -> clickhouse replica, then pg -> another pg with pg_clickhouse extension -> clickhouse This way we keep querying without changing the query language (use same postgres syntax), but switch connection port for analytics query. Experience so far: made 3 PRs to pg_clickhouse (1 merged), otherwise works pretty well. If something like pgrust would work even better/easier – would definitely check it out instead.
- petrizhang 1mo ago[flagged]
- saberience 1mo agoI tested pgrust against my own set of benchmarks a week or two ago and it crashed several times during testing. I would not trust this project further than I could throw it.
- malisper 1mo agoCan you file an issue? Our big focus over the next few weeks is to eliminate these issues and that's why we're our formal verification and fuzz testing work
- pgtriage 1mo ago[flagged]