Horton

Re: A design for amcheck heapam verification

Peter Geoghegan <pg@bowt.ie>

View thread View on postgr.es
From: Peter Geoghegan <pg@bowt.ie>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>, Michael Paquier <michael.paquier@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2017-09-29T17:57:58Z
Lists: pgsql-hackers 
On Fri, Sep 29, 2017 at 10:29 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> I am also wondering whether this patch should consider
> 81c5e46c490e2426db243eada186995da5bb0ba7 as a way of obtaining
> multiple hash values.  I suppose that's probably inferior to what is
> already being done on performance grounds, but I'll just throw out a
> mention of it here all the same in case it was overlooked or the
> relevance not spotted...

Well, we sometimes only want one hash value. This happens when we're
very short on memory (especially relative to the estimated final size
of the set), so it's a fairly common requirement. And, we have a
convenient way to get a second independent uint32 hash function now
(murmurhash32()).

-- 
Peter Geoghegan

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.