Horton

Re: A design for amcheck heapam verification

Alvaro Herrera <alvherre@2ndquadrant.com>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2017-08-30T12:02:10Z
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

Commits

  1. Fix non-portable use of round().

  2. Add amcheck verification of heap relations belonging to btree indexes.

  3. Add Bloom filter implementation.

  4. Use ereport not elog for some corrupt-HOT-chain reports.

  5. Introduce 64-bit hash functions with a 64-bit seed.

  6. Upgrade src/port/rint.c to be POSIX-compliant.

  7. Use type "int64" for memory accounting in tuplesort.c/tuplestore.c.