On Sun, Sep 18, 2011 at 6:14 PM, Craig James wrote:
> Regarding the recent discussion about hash versus B-trees: Here is a trick I
> invented years ago to make hash indexes REALLY fast. It eliminates the need
> for a second disk access to check the data in almost all cases, at the cost
> of an ad
2011/9/19 Ondrej Ivanič :
> BTW, Does Postgres use Bloom filter anywhere?
I saw patches for at least in-memory bloom filters (for hash joins)
Not sure they're committed. I think so.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription
Hi,
On 19 September 2011 11:14, Craig James wrote:
> DBsig for a hash-collision chain is always the bitwise OR of every record in
> that hash-collision chain. When you add a record to the hash table, you do
> a bitwise OR of its signature into the existing DBsig. If you delete a
> record, you e
Regarding the recent discussion about hash versus B-trees: Here is a trick I
invented years ago to make hash indexes REALLY fast. It eliminates the need
for a second disk access to check the data in almost all cases, at the cost of
an additional 32-bit integer in the hash-table data structure.
