new PostgreSQL index type which outperforms B-Trees for many common cases. As a wild experiment, I'm entirely vibe coding this and not hand-writing it.
It works by specializing for the common case of read-only workloads and short, fixed-length keys/includes (int, uuid, text<=32b, numeric, money, etc - not json) and (optionally) repetitive key-values (a common case with short fixed-length keys). These kinds of indexes/tables are found in nearly every database for lookups, many-many JOIN relationships, materialized views of popular statistics, etc.
Currently, it's "starting to work" with 100% code coverage and performance that usually matches/beats btree in query speed. Due to compression, it can consume as little as 99.95% less memory (!) and associated "pressure" on cache/ram/IO. Of course, there are degenerate cases (e.g. all unique UUID, many INCLUDEs, etc) where it's about the same size. As with all indexes, performance is limited by the PostgreSQL executor's interface which is record-at-a-time with high overhead records. I'd love help coding a FDW which allows aggregates (e.g. count()) to be "pushed down" and executed in still requires returning every record instead of a single final answer. OTT help would be a FDW interface where substantial query plans could be "pushed down" e.g. COUNT().
The plan is to publish and open source this work.
I'd welcome collaborators and have lots of experience working on small teams at major companies. I'm based in NYC but remote is fine.
- must be willing to work with LLMs and not "cheat" by hand-writing code.
- Usage testing: must be comfortable with PostgreSQL and indexes. No other experience required!
- Benchmarking, must know SQL indexes and have benchmarking experience - no pgsql internals required.
- For internals work, must know C and SQL. PostgreSQL is tricky to learn but LLMs are excellent teachers!
- Scripting code is in bash, python and Makefile, but again this is all vibe coded and you can ask LLMs what it's doing.
- any environment is fine. I'm using linux/docker (multi-core x86 and arm) but would love help with Windows, native MacOS and SIMD optimization.
- I'm open to porting/moving to Rust, especially if that provides a faster path to restricted environments like AWS RDS/Aurora.
- your ideas welcome! but obviously, we'll need to divide and conquer since the LLMs are making rapid changes to the core and we'll have to deal with code conflicts.
naive q: could games detect when the user is "looking around" at breathtaking scenery and raytrace those? offer a button to "take picture" and let the user specify how long to raytrace? then for heavy action and motion, ditch the raytracing? even better, as the user passes through "scenic" areas, automatically take pictures in the background. Heck, this could be an upsell kind of like the RL pictures you get on the roller coaster... #donthate
Even without RT I think it'd be beneficial to tune graphics settings depending on context, if it's an action/combat scene there's likely aspects the player isn't paying attention to. I think the challenge is it's more developer work whether it's done by implementing some automatic detection or manually being set scene by scene during development (which studios probably do already where they can set up specific arenas). I'd guess an additional task is making sure there's no glaring difference between tuning levels, and setting a baseline you can't go beneath.
Can I ask more about this? I assume you created a procedure around making DDL changes to the global cluster... what was that procedure like? what tools did you use (create) to automate/script this? what failure modes did it encounter?
Bold of you to assume it was automated. The process I used was tmux with pane synchronization.
I asked to automate it (probably would've just been a shell script, _maybe_ Python, issuing SQL commands to stdin), but people were afraid of unknown unknowns.
It sounds like using less tokens (or, less output due to a more compact syntax) is like a micro-optimization; code should be written for readability, not for compactness. That said, there are some really compact programming languages out there if this is what you need to optimize for.
IMO it's more likely to get confused because there are less unique tokens to differentiate between syntax (e.x. pipe when we want bitwise-or or vice-versa)
I’ve heard it said before on HN that this is not true in general because more tokens in familiar patterns helps the model understand what it’s doing (vs. very terse and novel syntax).
Otherwise LLMs would excel at writing APL and similar languages, but seems like that’s not the case.
In general food production enjoys heavy government support...
... but then again, many industries do too. Libertarian tech bros think they are "self made" even in fact the government supported them with absolutely massive support, from government tech purchasing to supporting R&D and higher education to tax breaks to deregulation and more.
Your average industry can't enjoy net subsidies: the money has to come from somewhere, so you have to tax at least as much as you subsidise. (Modulo shifting taxation around over time via debt.)
Though I'm not sure what you are trying to say with your comment? Just because someone is in favour of reducing subsidies, doesn't necessary mean they want to abolish the government?
Just like Bob being in favour of a weightloss diet for a morbidly obese Alice, friend doesn't mean Bob wants their normal sized friend Charlie to starve himself to death (nor does Bob want Alice to continue losing weight once she reached a healthy weight).
The fact that you wrote this in reply to me makes me think you missed the point of my comment, which didn't actually have anything to do with subsidies - I was just pointing out they "growing wine to make grapes" is the wrong way round ;)
It doesn't have to be dead, that's a choice we made as a society. It's an artificial limitation if people wake up and vote against it while they still can
...and perfectly legal services too, e.g. joinmassive.com, brightdata, etc.
(they're used for gathering listing data from e-commerce sites, job boards, etc.)
the problem is that TSLA (the company) is pivoting hard to humanoid robots, which is a relatively easier problem, perfectly big market and Musk is a terrific salesguy. Medium/long term, humanoid robots are commodity but so were electric cars and TSLA (the stock) rode that to glory.
Eh? _Useful_ humanoid robots are if anything considerably harder. Tech demos are easier, granted; humanoid robot tech demos date back to the 80s or so.
It works by specializing for the common case of read-only workloads and short, fixed-length keys/includes (int, uuid, text<=32b, numeric, money, etc - not json) and (optionally) repetitive key-values (a common case with short fixed-length keys). These kinds of indexes/tables are found in nearly every database for lookups, many-many JOIN relationships, materialized views of popular statistics, etc.
Currently, it's "starting to work" with 100% code coverage and performance that usually matches/beats btree in query speed. Due to compression, it can consume as little as 99.95% less memory (!) and associated "pressure" on cache/ram/IO. Of course, there are degenerate cases (e.g. all unique UUID, many INCLUDEs, etc) where it's about the same size. As with all indexes, performance is limited by the PostgreSQL executor's interface which is record-at-a-time with high overhead records. I'd love help coding a FDW which allows aggregates (e.g. count()) to be "pushed down" and executed in still requires returning every record instead of a single final answer. OTT help would be a FDW interface where substantial query plans could be "pushed down" e.g. COUNT().
The plan is to publish and open source this work.
I'd welcome collaborators and have lots of experience working on small teams at major companies. I'm based in NYC but remote is fine.
- must be willing to work with LLMs and not "cheat" by hand-writing code.
- Usage testing: must be comfortable with PostgreSQL and indexes. No other experience required!
- Benchmarking, must know SQL indexes and have benchmarking experience - no pgsql internals required.
- For internals work, must know C and SQL. PostgreSQL is tricky to learn but LLMs are excellent teachers!
- Scripting code is in bash, python and Makefile, but again this is all vibe coded and you can ask LLMs what it's doing.
- any environment is fine. I'm using linux/docker (multi-core x86 and arm) but would love help with Windows, native MacOS and SIMD optimization.
- I'm open to porting/moving to Rust, especially if that provides a faster path to restricted environments like AWS RDS/Aurora.
- your ideas welcome! but obviously, we'll need to divide and conquer since the LLMs are making rapid changes to the core and we'll have to deal with code conflicts.
DM to learn more (see my HN profile)