Re: A design for amcheck heapam verification

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

In response to

Responses

Browse pgsql-hackers by date

  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