From: | Benjamin Coutu <ben(dot)coutu(at)zeyos(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Cc: | Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Using ASSUME in place of ASSERT in non-assert builds |
Date: | 2025-07-10 14:24:08 |
Message-ID: | 81a3b62b5cdf97b74f30@zeyos.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
I noticed that Andres recently introduced pg_assume into the codebase - great addition!
That got me thinking: some projects (like PHP) map the ASSERT macro to ASSUME in non-assert builds. The rationale is that ASSERT typically expresses a tautology, something the programmer believes to be always true. So in builds where assertions are compiled out, we can still pass that information to the optimizer via ASSUME.
This approach has the advantage of keeping the semantics consistent: developers write ASSERT(...) as usual, and the compiler either enforces it at runtime (assert builds) or uses it as a hint (non-assert builds). There's no need to write separate logic or macros depending on build type. And we get the benefits of both safety and optimization.
Was this strategy considered before introducing pg_assume, or did I miss that part of the discussion?
Cheers
--
Benjamin Coutu
http://www.zeyos.com
From | Date | Subject | |
---|---|---|---|
Next Message | Mihail Nikalayeu | 2025-07-10 14:30:15 | Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements |
Previous Message | Bertrand Drouvot | 2025-07-10 14:17:21 | Re: Adding basic NUMA awareness |