Re: [HACKERS] A design for amcheck heapam verification

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] A design for amcheck heapam verification
Date: 2018-02-08 14:05:51
Message-ID: B0C6B39F-EEDA-4D04-A089-F808EA74C7A8@yandex-team.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi, Peter!

> 8 февр. 2018 г., в 4:56, Peter Geoghegan <pg(at)bowt(dot)ie> написал(а):
>
> * Faster modulo operations.
> ....
> * Removed sdbmhash().

Thanks! I definitely like how Bloom filter is implemented now.

I could not understand meaning of this, but apparently this will not harm
+ /*
+ * Caller will probably use signed 32-bit pseudo-random number, so hash
+ * caller's value to get 64-bit seed value
+ */
+ filter->seed = DatumGetUInt64(hash_uint32_extended(seed, 0));
I do not see a reason behind hashing the seed.

Also, I'd like to reformulate this paragraph. I understand what you want to say, but the sentence is incorrect.
+ * The Bloom filter behaves non-deterministically when caller passes a random
+ * seed value. This ensures that the same false positives will not occur from
+ * one run to the next, which is useful to some callers.
Bloom filter behaves deterministically, but differently. This does not ensures any thing, but probably will give something with hight probability.

Thanks!

Best regards, Andrey Borodin.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Dolgov 2018-02-08 14:14:42 Re: JIT compiling with LLVM v10.0
Previous Message Amit Kapila 2018-02-08 14:04:04 Re: [HACKERS] PATCH: enabling parallel execution for cursors explicitly (experimental)