Hacker News Reader: Best @ 2026-01-22 12:50:58 (UTC)

Consensus: Skeptical — most commenters treat the sale as financially small but symbolically meaningful, reflecting wider concern about U.S. fiscal credibility and reserve-currency risk.

Top Critiques & Pushback:

• Too small to move markets: Many note $100M is trivial against daily Treasury volumes and total foreign holdings; they view the action as largely symbolic (c46693352, c46692928).
• Practical, not political: Several argue pension managers primarily follow yield and risk mandates, so the move likely reflects portfolio risk management rather than a deliberate geopolitical protest (c46701283, c46693319).
• Domino / self-fulfilling concern: Others warn that if many funds replicate this behavior it could become meaningful — debate centers on whether selling would cause a run or be absorbed by Treasury/Fed actions (monetization/printing) that shift the impact to inflation (c46693776, c46692927, c46693125).
• Sell-side pain for smaller economies: Critics point out divesting the dollar can hurt the seller (Denmark/small funds) relatively more than the U.S.; it's not a cost-free signal (c46694286).

Better Alternatives / Prior Art:

• Currency / sovereign diversification: Commenters suggested diversifying into EUR/JPY/CNY or using IMF SDRs / other sovereign bonds as alternatives (c46693170, c46697696).
• Precious metals & crypto: Gold was frequently mentioned as a capital-preservation hedge; bitcoin was suggested by some but criticized for volatility (c46697904, c46704727).
• Already a trend: Several pointed out China and other holders have been reducing Treasury exposure for months — the move fits into a broader dedollarization conversation (c46693018).

Expert Context:

• Scale and signalling: Some commenters provided useful context on scale: a single $100M sale is negligible but repeated, larger sell-offs could matter (estimates of cumulative impact and foreign-holding math were discussed) (c46696497, c46693352).
• Policy mechanics: Users highlighted that political pressure on the Fed or Treasury responses (e.g., monetization) would likely shift risk from outright default toward inflation, which undermines Treasuries' role as a safe asset — a key reason funds might de-risk (c46693817, c46693125).

Consensus: Cautiously Optimistic — commenters broadly like the goal of reducing cross‑border friction, but many doubt the final law will avoid national red tape or fully fix tax/employment/residency frictions.

Top Critiques & Pushback:

• Bureaucratic capture / notary friction: Major worry that EU–INC will be filled with a "committee laundry list" of national requirements and notaries will preserve slow, costly steps rather than removing them (46704872, 46705361, 46706468).
• Doesn't solve tax/residency/employment rules: Repeated point that corporate law alone won’t override national tax, payroll or permanent‑establishment rules, so hiring, VAT and corporate tax frictions remain (46704992, 46711762, 46705264).
• Dissolution & practical frictions remain: Several users flagged that closing a company in many EU states is often harder and costlier than forming one, and EU–INC may not address insolvency/exit complexity (46709240, 46709655).
• Campaign legitimacy & political feasibility: Questions about who runs eu‑inc.org (merch/ToS flagged) and reminders that previous pan‑EU company attempts were blocked by member‑state politics, especially German resistance (46705363, 46709389, 46704296).

Better Alternatives / Prior Art:

• Estonia / e‑residency & digital formation: Commenters point to Estonia’s online notarisation and e‑residency as a working model for fast, low‑friction formation (46705555, 46709841).
• Use friendly jurisdictions and service providers: Practical workarounds mentioned include forming in friendlier states (UK, Ireland, Estonia) or using third‑party MoR/EOR and VAT/accounting platforms (Avalara, MoR services) to operate across borders today (46704513, 46713754, 46706695).

Expert Context:

• Incorporation paperwork ≠ safety: A legal‑minded commenter stressed heavy formation requirements mainly burden honest founders and don’t stop intentional wrongdoing — “There is no real point in making this a burden for honest people.” (46709463).
• Political history matters: Several remind readers that earlier pan‑EU private‑company proposals (SUP, SPE attempts) stalled over national politics and board/worker representation disputes — member‑state objections (notably Germany/Austria) are a real risk (46717768, 46706468).
• Formation vs ongoing costs: Multiple commenters noted that while formation speed matters, many founders are more hindered by continuing regulatory, tax and labour‑law costs — the US/EU contrast often shows easier formation in the US but persistent operational differences (46706878, 46709240).

Consensus: Skeptical — HN commenters generally accept that de‑dollarization is occurring in pockets (reserves, commodities, some bond flows) but are skeptical that the dollar will be rapidly or fully replaced given its liquidity and network effects.

Top Critiques & Pushback:

• Yuan as a replacement is implausible: Many argue China’s capital controls, limited investor protections and lack of full convertibility make CNY an unreliable global reserve (c46694181, c46695132).
• Euro has structural limits: Commenters note the euro’s political/fiscal fragmentation and unresolved institutional issues make it an imperfect substitute (c46696393, c46694029).
• Liquidity and network effects keep the dollar entrenched: Users emphasize the depth of U.S. capital markets, Treasuries, the Eurodollar plumbing and EM deposit dollarization as reasons the USD remains the practical medium for trade and settlement (c46694725, c46694424, c46694484).

Better Alternatives / Prior Art:

• Gold: Frequently cited as a store‑of‑value alternative and the subject of rising central‑bank purchases (commenters point to gold as a reserve hedge) (c46694100).
• BRICS / regional clearing & payment systems: Raised as a medium‑term substitute (New Development Bank, BRICS PAY), but many call these initiatives aspirational or limited in reach (c46699539, c46699261).
• Bancor / supranational basket ideas: Occasionally mentioned as a theoretical alternative to a single reserve currency (c46696428).
• Bitcoin and crypto: Brought up by some as a candidate, but met with strong skepticism over legal risk, on‑chain resilience and lack of sovereign backing (c46694758, c46695381).

Expert Context:

• Triffin dilemma reminder: Commenters flagged the long‑standing tradeoff for a reserve issuer — supplying the world with liquidity erodes domestic balance and can undermine confidence over time (c46694679).
• Weaponization of reserves: Several users pointed to the precedent of seized/blocked foreign reserves (e.g., Russian reserves) as accelerating the search for alternatives and undermining trust (c46698850).
• Eurodollar & liquidity nuance: Knowledgeable commenters stressed that much USD activity sits outside U.S. onshore control (the Eurodollar system), which complicates simple narratives about Fed control over global USD use (c46694725, c46695696).

Overall, the HN thread largely mirrors the article’s framing: evidence of erosion in specific channels (reserves, commodities, foreign Treasury holdings) but broad skepticism that the dollar’s transactional dominance will evaporate soon without major institutional changes or a credible, liquid alternative.

Consensus: Cautiously Optimistic — readers find the challenge interesting and educational, but many worry it’s an awkward or unfair hiring filter given ambiguity and fast-moving LLM capabilities.

Top Critiques & Pushback:

• Ambiguous spec / reverse-engineering burden: Several commenters note the assignment is as much about understanding an underspecified simulator and Python glue as about optimization, which can be frustrating and time-consuming (46703086, 46703000).
• Time commitment and fairness: Many say it demands many hours to do well (not a short take-home), which is unreasonable for applicants who are balancing other commitments (46708657, 46707392).
• LLMs change the signal / cheating concerns: Readers demonstrated that modern agentic LLMs and model harnesses substantially reduce time-to-solution and reach competitive cycle counts. That raises concerns the exercise now measures LLM-plus-prompt-engineering as much as human skill; commenters also flagged easy "cheats" like preloading final state if not explicitly forbidden (46701988, 46702357, 46702687).
• Messy baseline code / tooling friction: Several people complained the untyped, awkward Python and ad-hoc variables made the problem more about code scavenging than algorithmic optimization (46704876, 46703857).
• Precomputation controversy: At least one commenter withdrew their application after arguing that precomputing static data (or similar build-time shortcuts) should be allowed — they claim Anthropic retroactively tightened rules in README when challenged (46715598, 46702687).

Better Alternatives / Prior Art:

• Demoscene / code-golf analogy: Multiple readers liken the task to demoscene/code-golf style micro-optimization contests — fun if you like low-level tuning (46701424, 46702813).
• Profiling & harnesses: Commenters recommend using the provided tracing (Perfetto/Chrome trace) and community harnesses (e.g., voratiq) to reproduce and benchmark model-driven approaches (46702671, 46705965).
• Follow-up interviews: Some suggest using this as an invite to deeper, human-evaluated interviews rather than a terminal filter, since LLMs can now solve many take-homes (46707392).

Expert Context:

• GPU/TPU-style problem: Knowledgeable commenters explain the task behaves like a GPU/TPU kernel-optimization problem (static parallelism, pipeline depth, broadcast loads, difficult parallel tree-walks), so it naturally rewards people with low-level throughput/pipelining experience (46704070, 46703086).
• LLMs excel at micro-optimizations: Several participants note that assembly-like program generation and pattern-based micro-optimizations are an area where agentic code models are unusually effective, explaining why Claude/GPT runs perform well here (46701988, 46702357).

Notable reported results (from thread): humans have reported getting into the ~1100–1200 cycle range in extended, manual work (46703995, 46709173); model/agent runs reported a wide spread of outcomes depending on model, prompt, and harness (46701988, 46702398).

Consensus: Cautiously Optimistic — readers are excited by the WebGPU performance potential but raise concrete concerns about fidelity, data layout, demos and provenance.

Top Critiques & Pushback:

• Sampling can remove important peaks: Demo downsampling (LTTB / blind sampling) can hide peaks and distort statistics; commenters recommend offering a 'no sampling' mode or adaptive/pixel-aware/min–max sampling to preserve critical features (c46709415, c46719109, c46712759).
• Inefficient data representation: The example uses nested arrays (e.g., [[x,y],...]) which causes many small allocations; users urge columnar/typed-array APIs (Float32Array/Float64Array) to reduce GC and improve throughput (c46709415, c46719109).
• Idle CPU and UI bugs: Observers reported a continuously ticking render loop and a buggy data‑zoom slider; the author later pushed fixes (idle CPU pause, benchmark toggle), but UI quirks were raised by multiple users (c46709415, c46715091, c46707865).
• Not unique at scale: Several commenters pointed out Plotly, Graphistry and finance-focused engines already render multi‑million points; a 1M demo is notable but not unprecedented at industry scale (c46708319, c46709611, c46714243).
• Demo quality vs optimized 2D: Some maintainers said the live‑stream demo underperformed compared to well‑tuned 2D/canvas approaches, suggesting more optimization work beyond simply moving to GPU (c46710640).
• AI / provenance concerns: A number of users flagged agent/AI files in the repo and questioned how much of the code/documentation was AI‑generated (c46710710, c46711010).

Better Alternatives / Prior Art:

• uPlot: Lightweight, high‑performance canvas renderer with adaptive/min–max sampling strategies and multi‑million point demos used as a practical baseline (c46709415, c46709511).
• Plotly (WebGL): WebGL-backed scatter/point engines that have supported >10M points in production examples (c46708319).
• Graphistry: GPU-backed graph/event visualization stack for very large graphs and hitmapping (c46714243).
• virtual-webgl (greggman): Known workaround to virtualize GL contexts on pages with many charts (c46709415).

Expert Context:

• Sampling & fidelity: The uPlot maintainer warns that default sampling affects visual fidelity and apples‑to‑apples comparisons; he recommends exposing a no‑sampling option and supporting columnar/typed arrays to avoid allocation overhead (c46709415).
• Adaptive/min‑max approaches work well in practice: The original Flot maintainer and audio‑plotting commenters recommend pixel‑aware adaptive sampling or storing min/max per block (client‑side mipmapping) to preserve peaks while reducing rendered points (c46712759, c46713429).
• Density mapping tradeoffs: Density/"digital phosphor" (binning points into intensity grids) is a suggested alternative for overplotted datasets; commenters debate a simple blending pass versus explicit compute‑shader binning (blending is simpler, compute is faster/precise) (c46708855, c46709568, c46710347).
• Browser limits matter: Chrome/Edge historical GL context limits mean dashboards with many GPU charts need strategies (e.g., virtual‑webgl) to avoid per‑tab context caps (c46709415).

Consensus: Cautiously Optimistic — readers are intrigued and appreciative of the monument and its Long Now resonance, but many are concerned about its condition and long‑term preservation (46697087, 46697675).

Top Critiques & Pushback:

• Conflicting reports about damage and restoration: Some users linked an account implying the star map was demolished or taken up around 2022 due to drainage/contract issues (46697087, 46697305), while others posted recent photos or updates suggesting reconstruction work or that parts were open again (46699282, 46699521, 46697675).
• Long‑term fragility / site viability: Commenters flagged that Hoover Dam and Lake Mead face long‑term physical changes (siltation, changing utility), raising doubts about preserving a millennia‑spanning message tied to a vulnerable infrastructure (46709842).
• Privacy concerns about shared photos/links: A handful of users noted that posting direct photo links from personal accounts can risk doxxing HN participants (46699968).

Better Alternatives / Prior Art:

• Skyfield (Python): Recommended by commenters for computing planetary positions and building/reversing such maps; several users described workflows using it (46698833, 46699045).
• Celestia / visualization tools: Suggested for simulating star/planet views (46698422).
• Commercial star‑map makers: For people who want smaller, robust versions (e.g., TheNightSky) (46700972).
• Long Now / ancient examples: The project connects conceptually to the Long Now 10,000‑Year Clock and to historical precession references (Thuban, Kochab) discussed in comments (article + 46697123, 46696315).

Expert Context:

• Astronomical notes: Commenters summarized relevant astronomy—Thuban was near the pole at the time of the pyramids, Kochab mattered in the 1st millennium BC, Polaris is current, Vega will be a future pole star; precession and proper motion are the key effects being encoded (46696315).
• Climate/long‑term cycles: Milankovitch cycles and orbital changes were mentioned as broader context for long timescales (46699828).
• Technical reproduction & inverse dating: A commenter who built a pendant explained using Skyfield for ephemerides, CNC/laser workflows for fabrication, and an inverse search (binary narrowing + refinement) to recover dates from a planetary snapshot; they also noted Galilean moons move fast enough to encode sub‑hour timing (46698833, 46699045, 46697220).

Consensus: Cautiously Optimistic — readers generally appreciate the transparency and the move toward principle-based steering, but many raise serious practical and ethical concerns.

Top Critiques & Pushback:

• Relativism vs. moral absolutes: Some commenters worry the constitution's emphasis on "practical wisdom" rejects fixed, universal moral standards and could let Anthropic's contingent values become de facto norms for powerful systems (c46712541). Defenders reply the doc acknowledges the limits of exhaustive rule-lists and still provides anchors and hard constraints (c46712727).
• Missing explicit human-rights protections: Critics note the constitution reads like operational guardrails for what an LLM can do rather than a rights charter (missing explicit bans on torture/slavery was flagged) and worry about omitted guarantees for individual rights (c46716991). Others point out that the document does include operational "hard constraints" targeted at realistic LLM harms (e.g., bioweapon uplift) (c46713334).
• Specialized/government models & commercialization: Multiple readers flagged that the constitution only covers "mainline" public Claude models and expressed concern that specialized or government deployments (and Anthropic partnerships) might not adhere to it (c46711490, c46714928).
• PR, anthropomorphizing, and messaging: Some view the release as partly PR or employee-facing messaging that could encourage anthropomorphizing Claude (c46709552, c46711220); others emphasize its practical value as a training artifact and documentation for system prompt authors (c46710449).

Better Alternatives / Prior Art:

• Constitutional AI & leaked documents: Commenters linked this release to Anthropic's prior Constitutional AI research and earlier leaked "soul" documents, treating the new constitution as an iteration on existing methods (c46709609, c46710012).
• Rights-first frameworks (UDHR-style): Several suggested that rights-based, explicit prohibitions (e.g., torture/slavery) are a useful comparator and missing lens for the constitution's framings (c46716991).
• Prose/principle steering over rule-lists: Practitioners noted that explanatory prose and principle-based guidance generalize better when steering models than enumerated rule lists, and pointed to training/distillation techniques as the operational approach (c46710449, c46717292).

Expert Context:

• How it's used in training: Informed commenters explained the constitution is primarily a training-time artifact (used in context windows, to generate and rank synthetic examples, and to distill behaviors into model weights), not just a user-facing system prompt — which explains why its prose emphasizes reasons and tradeoffs (c46710449, c46709609).
• Operational focus of hard constraints: Several technically minded readers observed the hard constraints are tailored to harms an LLM could plausibly enable (bioweapon uplift, cybersecurity/infrastructure assistance, etc.), rather than attempting a full human-rights charter — a design choice that explains some of the document's omissions (c46713334, c46716991).

Consensus: Cautiously Optimistic — readers welcome the break from drought but many emphasize this is likely temporary.

Top Critiques & Pushback:

• Headline vs. snapshot: Several commenters say the headline overstates long-term change; near-zero versus zero is largely cartographic and similar "drought-free" snapshots have appeared in past winters (c46700016, c46704339).
• Metrics and definition concerns: Users argued that "abnormally dry" on the Drought Monitor (soil-moisture–focused) is not the same as overall water-security; supply depends on reservoirs, snowpack and groundwater timing — commenters flagged the need to distinguish map categories from actual shortages (c46704327, c46709218, c46698827).
• Structural water-management issues: Many pointed out institutional drivers (agricultural water rights, low pricing, transfers to urban areas like Los Angeles) that headline snapshots don't address; structural reforms would matter more than a single wet season (c46709909, c46702222).

Better Alternatives / Prior Art:

• Broader metrics: Commenters recommend combining Drought Monitor maps with reservoir, snowpack and groundwater datasets to assess real water availability (c46709218).
• Demand- and supply-side fixes: Suggestions included market-based pricing/reallocation of water (c46700354), regenerative land practices to increase landscape water retention (c46709603), and desalination as a supply hedge with attention to energy costs (c46702406, c46702450).

Expert Context:

• Hydroclimate whiplash & fuels: Both the article and commenters note wet winters can boost grass and brush growth that becomes fuel in subsequent dry spells, so a wet season does not eliminate future wildfire risk (article; c46699740).
• Data nuance: A knowledgeable commenter emphasized that the Drought Monitor emphasizes soil moisture and that ongoing efforts aim to produce more comprehensive views that include precipitation, snowpack and storage (c46709218).

Consensus: Skeptical — the discussion broadly doubts a straightforward or "inevitable" crash to $100 and instead focuses on multiple demand, supply, and geopolitical factors that could push price either way.

Top Critiques & Pushback:

• Persistent GPU demand / Jevons paradox: Several commenters argue algorithmic improvements tend to expand use (not reduce it), so efficiency gains could increase GPU demand rather than shrink it (c46701542, c46710736).
• Chinese competition and supply‑side risk: A common bear case is a China‑based, cheaper CUDA‑compatible (or functionally equivalent) GPU entering the market or policy shifts changing market access — commenters say this could materially undercut NVIDIA (c46695727, c46702128).
• Customer concentration & order risk: Commenters point to Nvidia’s dependence on a few very large customers and the ease with which purchase orders can be delayed/cancelled as a concrete business risk that could precipitate revenue shocks (c46696098).
• Hardware lifecycle and refresh economics: There’s debate over how quickly datacenter GPUs are refreshed (1–3 years vs longer), with practical drivers including power, rack space, warranty/support terms, and depreciation — all relevant to future demand (c46696159, c46696217).
• Geopolitical / supply‑chain tail risks: Several users highlight Taiwan/TSMC and war or trade actions as low‑probability but very high‑impact events that could crash NVDA (or disrupt supply), while others note on‑shoring efforts and foreign fabs that partially mitigate the risk (c46693813, c46694037, c46696423).

Better Alternatives / Prior Art:

• Google TPUs / Trainium / custom accelerators: Multiple commenters note that TPUs (and other cloud/provider silicon) are already used for major models (e.g., Gemini) and are a real alternative to GPUs for large training runs (c46697083, c46697679).
• AMD / Groq / Apple / bespoke inference chips: Users point to AMD, Groq, or phone/edge inference silicon (Apple, custom inference silicon) as competitors or complementary solutions that reduce NVDA’s absolute dominance (c46698984, c46696423).
• Software/API efforts (OpenCL, Vulkan, OneAPI, ONNX): Several comments discuss the ecosystem lock‑in (CUDA) and whether cross‑platform stacks or LLM‑assisted porting could erode that moat (c46698984, c46698253).

Expert Context / Notable Corrections:

• One commenter cites Nvidia’s 2025 annual report showing a large share of revenue from three customers and reminds readers that many enterprise purchase orders can be cancelled or delayed ("34% of their sales for 2025 comes from just 3 customers") — a concrete business vulnerability (c46696098).
• Others push back on simple narratives around Google/TPU usage: Google’s public statements can mean the final run used TPUs even if many development/experiments used NVIDIA GPUs; that nuance matters for interpreting market reactions (c46697679).
• Practical datacenter insights (support contracts, rack/power constraints, and longer‑term reuse of cards) appear repeatedly and add texture to whether demand will evaporate or merely shift (c46696159, c46696248).

Bottom line for readers: the HN thread treats the article’s options‑based method as a useful quantitative check, but respondents emphasize many orthogonal fundamental and geopolitical risks that the option‑market calibration does not fully capture; views remain mixed rather than convergent.

Consensus: Cautiously Optimistic — the HN community welcomes Skip going open‑source but many want clearer answers on licensing, funding, and practical developer costs.

Top Critiques & Pushback:

• Sustainability concerns: Commenters ask how Skip will fund long‑term maintenance and worry donations won’t be enough; many expect enterprise paid support or add‑ons to be the primary revenue (c46716393, c46716851, c46716607).
• License & legal confusion: Early observers flagged that the main repo initially lacked a LICENSE; commenters reported the project added LGPLv3 and debated what that means for shipping apps — others clarified that using an (L)GPL build tool usually doesn’t impose the license on your app binary (c46708246, c46709101, c46716622).
• Heavy dev‑environment requirements: Several readers were alarmed by the recommendation of ~32GB RAM and macOS/Xcode requirements; others explained the RAM guidance mostly reflects running both iOS and Android toolchains, simulators and IDEs at once rather than Skip itself (c46709135, c46709262).
• Competition and tradeoffs: People debate whether Skip truly avoids cross‑platform compromises. Some view Skip as a native‑first solution that can keep up with new OS UI conventions; others point out mature alternatives (Flutter, KMP, React Native) and the practical costs of migration or lock‑in (c46710870, c46711038, c46713994).

Better Alternatives / Prior Art:

• Flutter: Frequently referenced as the incumbent cross‑platform option — praised for scale but criticized by some for apps that "feel Flutter" rather than native (c46713994, c46711038).
• Kotlin Multiplatform / Swift WASM: KMP is cited as another route to share logic; commenters also point to teams using Swift‑centric approaches like Swift→WASM (Goodnotes was mentioned) to reach multiple platforms (c46713331, c46716649).
• Native stacks: Several commenters recommend sticking to native Swift/Kotlin when product requirements or maintenance risk make a single framework brittle (c46713331).

Expert Context:

• LGPL clarification: Knowledgeable commenters explain that an LGPL‑licensed build tool generally does not "infect" the produced app binary — obligations apply if you ship or modify the LGPL component itself (c46716622, c46709101).
• Memory/tooling explanation: The 32GB recommendation is driven by running Xcode, Android Studio/Gradle and emulators simultaneously; Skip itself is not the primary memory consumer (c46709262).
• Accessibility & native toolkits: Several replies highlight that Skip maps to native toolkits (SwiftUI on iOS, Compose on Android), which should provide platform accessibility and conventions out of the box (c46709993).

Overall, commenters applaud the move to open source but want clearer signals about licensing details, enterprise vs. indie workflows, and the real‑world developer cost (hardware, CI, and maintenance) before betting on Skip for production apps.

Consensus: Cautiously optimistic — readers appreciated the practical, creative tips and real‑world demos, but many highlighted important caveats and tradeoffs.

Top Critiques & Pushback:

• MERGE and concurrency risks: Commenters warn MERGE can trigger TOCTOU‑style unique constraint errors under MVCC and concurrent inserts; many prefer INSERT ... ON CONFLICT or explicit transactional logic for OLTP workloads (46696549, 46698325).
• Hash‑index uniqueness confusion and limitations: Some raised collision concerns with hash‑based uniqueness (46698265); others clarified Postgres checks full values too (46698892). Still, the exclusion/hash approach prevents using that constraint as a foreign‑key target and makes some ON CONFLICT patterns awkward (article + comments).
• Write amplification and lack of index‑organized tables: Multiple readers discussed write amplification from separate heap + indexes and wished for true index‑organized/clustered tables; CLUSTER is a one‑time physical reorder and not an automatic index‑organized table replacement (46698599, 46699318, 46702629).
• Fragility of expression indexes: Function‑based indexes are brittle unless you force a single expression (views or virtual columns); without that discipline analysts will bypass the optimized path (46697393).

Better Alternatives / Prior Art:

• BRIN indexes: Suggested for mostly monotonic timestamp or append‑only data as a tiny, high‑performance option (46699779, 46699987).
• Tablespaces / separate disks: Placing indexes on different physical storage (tablespaces) to reduce I/O contention was proposed (46699614, 46699749).
• Clustered / index‑organized tables in other DBs: Commenters pointed out that some systems (SQLite, MySQL storage engines, MSSQL/Oracle options) provide index‑organized or clustered PKs to reduce duplicate writes (46699318, 46698992, 46702629).
• Bulk-load best practices: Use COPY (binary) for large imports for speed; be mindful of conflict handling limitations (46696660, 46697414).

Expert Context:

• MERGE semantics vs MVCC: Knowledgeable commenters explain MERGE’s semantics interact poorly with MVCC and concurrent inserts, making INSERT ... ON CONFLICT or transactional retries preferable in many OLTP scenarios (46696549, 46698325).
• Hash index behavior clarified: A commenter noted Postgres still compares full values (so hash collisions don’t by themselves cause silent duplicates), but the functional limitations of exclusion/hash uniqueness remain (46698892).
• CLUSTER ≠ index‑organized table: Several replies emphasize that PostgreSQL’s CLUSTER is a manual/one‑time reorder, not an automatically maintained index‑organized table like Oracle/SQL Server provide (46702629).