From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: A design for amcheck heapam verification |
Date: | 2017-08-30 12:02:10 |
Message-ID: | 20170830120210.oldcempsfm27mrs4@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Geoghegan wrote:
> > Your patch brings us one step closer to that goal. (The book says
> > that this approach is good far sparse bitsets, but your comment says
> > that we expect something near 50%. That's irrelevant anyway since a
> > future centralised popcount() implementation would do this in
> > word-sized chunks with a hardware instruction or branch-free-per-word
> > lookups in a table and not care at all about sparseness.)
>
> I own a copy of Hacker's Delight (well, uh, Daniel Farina lent me his
> copy about 2 years ago!). pop()/popcount() does seem like a clever
> algorithm, that we should probably think about adopting in some cases,
> but I should point at that the current caller to my
> bloom_prop_bits_set() function is an elog() DEBUG1 call. This is not
> at all performance critical.
Eh, if you want to optimize it for the case where debug output is not
enabled, make sure to use ereport() not elog(). ereport()
short-circuits evaluation of arguments, whereas elog() does not.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Khandekar | 2017-08-30 12:02:52 | Re: Parallel Append implementation |
Previous Message | Pavan Deolasee | 2017-08-30 12:00:39 | Re: Parallel worker error |