I was just about to ask some friends about it. If I’m not mistaken, Postgres began using ICU for collation, but not string matching yet. Curious if someone here is working in that direction?
I have seen a lot of people sort by (generated) integer values to return the rows "in creation order" assuming that sorting by an integer is somehow magically faster than sorting by a proper timestamp value (which give a more robust "creation order" sorting than a generated integer value).
Assuming the integer value is the PK, it can in fact be much faster for MySQL / MariaDB due to InnoDB’s clustering index. If it can do a range scan over the PK, and that’s also the ORDER BY (with matching direction), congratulations, the rows are already ordered, no sort required. If it has to do a secondary index lookup to find the rows, this is not guaranteed.
(I have family and lots of close friends in the US. I miss them all. But I don't intend to visit given the way things are over there these days. _Maybe_ after the next administration change? Depending on how things change? But I've come to accept I may never visit again.)
I already missed a funeral on account of all this bs. But it just doesn't seem worth the hassle any more to go there. It is frustrating because I have more friends on that side of the Atlantic than I do in the EU. But the last interaction with US border patrol was enough to sour me for the rest of my life.
I've been to the US multiple times this year and it's really not much different from how its been for the last decades. If you are choosing to to not go to events that you would want to attend over this you only have yourself to blame.
I only have bluesky with only work posts, nothing else. I've gotten a visa in last few months. Even though I never went because of the situation. Needed to get a visa for potential work related stuff which eventually could be worked around.
The German Wikipedia page[1] about the Z1 also contains a quote from Kurt Pannke, who Zuse told about his plans for the computer.
"Oh, Mr Zuse, there is absolutely nothing left to invent in the field of calculating machines. But you are a nice young engineer, I'll give you 1,500
Reichsmarks and when you have come up with something, show it to me."
(Translated by Deepl)
I like the "640K ought to be enough" vibe of that statement :)
“Lithotripsy” is the name of the kidney stone treatment. My understanding is it’s based on vibration, not ultrasound (I know, vibration is sound - my understanding is the method on the linked article uses higher frequency + intensity + shorter pulses than the kidney stone method - so sorta like microwaving tumors vs using a massage gun on kidney stones?)
My surgeon told me my previous kidney cancer surgery (partial nephrectomy) meant my 7/8 size kidney wouldn't handle ultrasound treatment for the big kidney stone I'd developed 10 years after the cancer. So laser instead! Worked well but not much fun at the time.
Having had kidney stones, they're both used. I think for the sonic one they put you in a water bath because it conducts better. But as I understand it, the docs can pick whichever one is more optimal, be it shattering the stone sonically or zapping it with a laser.
AFIKR two facilities do this kind of treatment. One in Canada and one in China. There already was a HN threads with some reporting to have been treated in Canada.
Apparently, only some tumors have a distinct and unique shape / size. The “trick” is to calibrate the resonance exactly to the size of the cancer cell. So that resonance would “hurt” only that kind of shape / size cell. Which was much harder to do than it sounds. Sadly not all cancer cells are unique and not that “easily” distinguishable by size
But I am not in the medical field and just repeating what I’ve read.
yup. If the stone is mineral-based and within certain sizes, you can break it up with a special ultrasound. Except.... in morbidly obese patients, if you can imagine the why.
Not sure on which Postgres version this was tested with, but the first example runs in about 2ms with my Postgres 17 installation ("cold cache"). It uses a BitmapOr on the two defined indexes.
When you say cold cache, did you clear the os page cache as well as the postgres buffercaches? After setup.sql, the cache will be warmish - I get 4ms on the first run. I'm using postgres 17.5
I did not explicitly evict the Postgres buffer cache, but using pg_buffercache to evict all buffers for the table, yields a runtime of 23ms for me (still going for the BitmapOr).
reply