<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: hbirler</title><link>https://news.ycombinator.com/user?id=hbirler</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Sat, 12 Sep 2026 08:18:08 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=hbirler" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by hbirler in "QueryBrew: System-Agnostic SQL-to-SQL Query Optimization [pdf]"]]></title><description><![CDATA[
<p>Hello, paper co-author here.
QueryBrew is based on our research relational database Umbra (<a href="https://umbra-db.com/" rel="nofollow">https://umbra-db.com/</a>) which has been in development since around 2018. 
Our optimizer needs to produce correct plans within milliseconds while considering thousands to millions of alternatives, so using machine learning based approaches is often not a great fit. We instead rely on purpose-built algorithms like query decorrelation (<a href="https://15799.courses.cs.cmu.edu/spring2025/papers/11-unnesting/neumann-btw2025.pdf" rel="nofollow">https://15799.courses.cs.cmu.edu/spring2025/papers/11-unnest...</a>) and DP based join ordering (<a href="https://dl.acm.org/doi/pdf/10.1145/3183713.3183733" rel="nofollow">https://dl.acm.org/doi/pdf/10.1145/3183713.3183733</a>).
We have used AI for fuzzing input queries to test the optimizer.</p>
]]></description><pubDate>Sat, 12 Sep 2026 00:36:34 +0000</pubDate><link>https://news.ycombinator.com/item?id=49667347</link><dc:creator>hbirler</dc:creator><comments>https://news.ycombinator.com/item?id=49667347</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49667347</guid></item><item><title><![CDATA[New comment by hbirler in "I wrote a SQL engine in Python"]]></title><description><![CDATA[
<p>A Python to SQL compiler already exists <a href="https://db.cs.uni-tuebingen.de/publications/2022/snakes-on-a-plan-compiling-python-functions-into-plain-sql-queries/" rel="nofollow">https://db.cs.uni-tuebingen.de/publications/2022/snakes-on-a...</a></p>
]]></description><pubDate>Fri, 30 Dec 2022 21:57:06 +0000</pubDate><link>https://news.ycombinator.com/item?id=34190582</link><dc:creator>hbirler</dc:creator><comments>https://news.ycombinator.com/item?id=34190582</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=34190582</guid></item><item><title><![CDATA[New comment by hbirler in "NoJS – Creating a calculator with only HTML and CSS"]]></title><description><![CDATA[
<p>Multiplying the 32bit floats 99999.0f and 9999.0f results in 999889984 (Firefox's result). So I guess this hints at what Firefox might be doing :)<p>Float multiplication's result: <a href="https://godbolt.org/z/q857f51GP" rel="nofollow">https://godbolt.org/z/q857f51GP</a></p>
]]></description><pubDate>Fri, 21 Jan 2022 23:38:41 +0000</pubDate><link>https://news.ycombinator.com/item?id=30031409</link><dc:creator>hbirler</dc:creator><comments>https://news.ycombinator.com/item?id=30031409</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=30031409</guid></item><item><title><![CDATA[New comment by hbirler in "NoJS – Creating a calculator with only HTML and CSS"]]></title><description><![CDATA[
<p>For 99999 x 9999:<p>Firefox 96 displays 999889984<p>Edge 97 displays 999890001<p>The answer should be 999890001, so Edge is right and Firefox is wrong</p>
]]></description><pubDate>Fri, 21 Jan 2022 23:29:47 +0000</pubDate><link>https://news.ycombinator.com/item?id=30031322</link><dc:creator>hbirler</dc:creator><comments>https://news.ycombinator.com/item?id=30031322</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=30031322</guid></item></channel></rss>