Viewing profile — petergeoghegan

Why are you using hash indexes? They're much less widely used than standard B-Tree indexes. The bucket split code likely isn't very scalable [1]. I suggest testing the same workloa…

> The section on multi-column indexes mirrors how I was taught and how I’ve generally handled such indexes in the past. But is it still true for more recent PG versions? No, it isn…

> I may not be remembering fully, maybe the indexes never shrunk but the tables did in size. That only happens when it is possible to give back space to the OS filesystem using rel…

No, it does not

> In a previous use case, when using postgres as a WAL-like append only store, I noticed that indexes would get massive. Then, after a while, they'd magically shrink. It's possible…

Can you provide more detail/a reference? I've done extensive work on improving the Postgres B-Tree code, over quite a number of releases. I'm not aware of any problems with high-in…

Recent versions of clangd show pahole-like struct size/alignment padding overhead annotations. I find this built-in support a lot more convenient than using pahole.

"So far, so good. What's the problem here? The DDL statement can simply wait patiently until it's able to acquire its ACCESS EXCLUSIVE lock, right? The problem is that any other st…

> It is certainly possible that the plans are similar, and that improvements to the execution engine are being measured. The join order benchmark was designed to test optimizer qua…

> Your code can no longer be compiled by a compiler that does not support these special C dialects. What compiler might that be? It's true that MSVC doesn't have an equivalent of -…

> Postgres has commercial backing and inertia, but it seems like we are lacking a pipeline of (proficient) C developers. It's difficult to get into Postgres development, but that h…

What most users want is a statement that allows them to UPSERT, with reasonable guarantees around that never throwing a duplicate violation error, and never deadlocking (at least n…

> insert...on conflict is a fine way to do upserts on older PostgreSQL versions. For modern ones (15+) there is a better alternative [SQL Standard: MERGE] This is incorrect. To quo…

> It's not taken seriously because it shouldn't be taken seriously I really don't know what you're arguing against. I never questioned the general usefulness of an abstract machine…

> No. This is what I call the "portable assembler"-understanding of undefined behavior and it is entirely false. "C has been characterized (both admiringly and invidiously) as a po…

> The real problem here is the x86 architecture Even if we could say for sure that x86 has been disproportionately affected by speculative execution bugs (which already seems dubio…

> On further reflection I think maybe reputation for performance matters rather than performance itself I think that you're vastly overestimating the importance C as an abstract sp…

> It reminds me of colonial Europeans passing judgement on the "savage" inhabitants of a place they've now decided belongs to them Okay!

> The justification for monstrously unsafe languages like C was that they're faster. I don't think that that's true. I find the explanation given by "Some Were Meant for C" [1] far…

> While I do sympathize with some of the user complaints with UB, and the issues with things like signed integer overflow and strict aliasing seem entirely gratuitous, I think most…

> Planners are too smart for their own good. I know what you mean, but I don't think that that quite captures it. It's more like this: planners are built on a set of assumptions th…

> C got various other things subtly right, too: manifestly enough to make up for its blatant failings. If you would displace C, it is much more important to retain its strengths th…

> When you write C programs, you are coding on the C abstract machine as specified by the language standard. Are you really, though? I would argue that it's a matter of perspective…

> You are understating the limitations of B+trees for real workloads. I never said anything about workloads. All I said was that your statements about B+Trees having dwindling usag…