Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
Sesse__
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
49 ms
·
751.
▲
by
Sesse__
3y ago
Not that I can remember, no. I don't have the details anymore; I delegated it to others to report to -perform, and then they never did. :-)
752.
▲
by
Sesse__
3y ago
Yes, a lot of this seems interesting to go into. I really hope that at some point, someone would find the resources to just try a lot of dumb stuff and see what works in practice. I mean, what we have right now (multiply selectivities toget
753.
▲
by
Sesse__
3y ago
FWIW, I've seen planning+query times triple with JIT on, with no partitioned tables involved. It just takes forever to JIT sometimes. (This was with Postgres 13 and 14, IIRC.) Update: I checked some old IRC logs, and found a query that
754.
▲
by
Sesse__
3y ago
https://www.vldb.org/pvldb/vol9/p204-leis.pdf
755.
▲
by
Sesse__
3y ago
Yeah, nestloop with a cheap inner path (e.g. a lookup into a unique index) should be just fine, so I don't think nestloops as a whole should be banned. (Also, I believe Postgres is pretty much the only place I've seen the concept
756.
▲
by
Sesse__
3y ago
It comes down to: What is the evaluation for? For a human using an engine to analyze, it is about getting to more win-likely positions. And for an engine, it really is the same; plus to guide the search. Having a perfect trinary win/dr
757.
▲
by
Sesse__
3y ago
You may be interested in this paper (and the papers it references): https://arxiv.org/pdf/1902.08291
758.
▲
by
Sesse__
3y ago
I do wonder if one could eventually just turn off nestloops in such a case (e.g. inner side contains a seqscan), like the JOB paper recommended. Yes, it will have marginally higher estimated cost, but the upside is _much_ safer query plans
759.
▲
by
Sesse__
3y ago
Because the poster (who also wrote some of the optimizations in question) works for Citus Data.
760.
▲
by
Sesse__
3y ago
The problem is that ORMs have a habit of making very silly queries, and developers insist they cannot write SQL to fix that, because it is somehow impure :-) I doubt this is a very _common_ issue, but I'm not surprised if it shows up e
761.
▲
by
Sesse__
3y ago
I believe the JIT is pretty much a failure, yes. It was well-meant, but LLVM just isn't the right tool for this. I've turned it off globally. (I don't use any ORMs, so it's not simply about strange query patterns.) Query
762.
▲
by
Sesse__
3y ago
I once had a coworker working on a refactoring branch for one and a half _years_. Just merging with the main branch after they had things working took weeks. Especially as we had switched coding styles and reformatted all the source code in
763.
▲
by
Sesse__
3y ago
Yeah, I know, I wrote the new executor and the hypergraph join optimizer (the one based on DPhyp), that's why I wondered :-) It's true that if you are using the hypergraph optimizer, you will get a rewrite from the array of tables
764.
▲
by
Sesse__
3y ago
After a quick look, I'm not sure if I would call this “industrial strength”. In particular, the join optimizer (typically the heart of a large-scale SQL optimizer) looks very rudimentary? And the statistics it uses have zero idea about
765.
▲
by
Sesse__
3y ago
An honest question, since you're there: Why do you consider MySQL 8.0's optimizer to be based on relational algebra? It's true that the new executor introduced in 8.0 is Volcano-style, but the optimizer is pretty much ad-hoc
766.
▲
by
Sesse__
3y ago
If nothing else: It's certainly useful that mother's milk tastes good to babies. Imagine what an evolutionary disadvantage it would be if it tasted bitter.
767.
▲
by
Sesse__
3y ago
There is a tiny minority of people who insist on speaking nynorsk exactly as it is written, usually in an archaic style like the 1917 normal. Ironically, these people tend to live in Oslo or surrounding areas, where the dialect is far and w
768.
▲
by
Sesse__
3y ago
The standardization of kitchens (to optimize the housewife's day, based on observations) also lead to the hilarious black comedy “Psalmer från köket” (English title “Kitchen stories”) where the premise is that the government tries to r
769.
▲
by
Sesse__
3y ago
Well, they are seemingly explicitly calling out Debian as your new favorite place for SSHv1 support :-) Who are no more paid than they are.
770.
▲
by
Sesse__
3y ago
So basically, the recommended solution is “instead of us maintaining DSA support, everybody should maintain their own fork of an old OpenSSH version”?
771.
▲
by
Sesse__
3y ago
Note that V8 didn't have a dumb-but-very-fast JIT (Sparkplug) until 2021; the interpreter (Ignition) did that block counting and sent it straight to the optimizing JIT (TurboFan). V8 pre-2021 (i.e., only Ignition+TurboFan) was signific
772.
▲
by
Sesse__
3y ago
Yeah, sounds about right. And yes, obviously it was much faster than GDI for games, since you had more or less direct access to a framebuffer. Not building up some device-independent bitmap and going through some slow path to convert it int
773.
▲
by
Sesse__
3y ago
DirectDraw wasn't really meant as a drawing toolkit; you _did_ have blits, but they were not hardware accelerated AFAIK and not nearly flexible enough for what the article suggests (mirror, stiple, probably other stuff). In general, wh
774.
▲
by
Sesse__
3y ago
This is sometimes called a “slider”. Difftastic has special logic to try to deal with sliders and get closer to what you want.
775.
▲
by
Sesse__
3y ago
The hobbyist Linux market generally tinkers with things like Raspberry Pis now, not ancient 32-bit x86 machines. (This is a natural consequence of the fact that sources for cheap hardware have changed a lot over the last twenty years.)
776.
▲
by
Sesse__
3y ago
I believe the last x86-compatible chips without 64-bit support were launched around 2006 or so (Intel Core; Core 2 had 64-bit support), a couple of years after Opteron initially came out. It's not really clear how long the Linux kernel
777.
▲
by
Sesse__
3y ago
> Debian, the so-called "universal operating system" just dropped 32-bit x86 support. This is imprecise at best. There was a meeting where the release team concluded that most likely, there will be no _installer_ and _kernel_ s
778.
▲
by
Sesse__
3y ago
If that is indeed a requirement, you let your iterator have an .at_end() test instead of trying to shoehorn it into the return value. Or have something like C++'s std::optional or Rust's Option. Or a special EndOfIteration object
779.
▲
by
Sesse__
3y ago
Also, you have craziness like quite regular iteration being implemented using exceptions, which are not exactly trivial to optimize.
780.
▲
by
Sesse__
3y ago
The bug system has a list of predetermined severities, so that would just be rejected. :-)
More ›