Re: BRIN indexes - TRAP: BadArgument - Mailing list pgsql-hackers

From Greg Stark
Subject Re: BRIN indexes - TRAP: BadArgument
Date
Msg-id CAM-w4HOhMP4kQTQzOR26st54-H9W5N_cda4ETYGkEbJJgY1-mg@mail.gmail.com
Whole thread Raw
In response to Re: BRIN indexes - TRAP: BadArgument  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: BRIN indexes - TRAP: BadArgument  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
It might be clearer to have an opclassinfo and a scaninfo which can
store information in separate opc_opaque and scan_opaque fields with
distinct liftetimes.

In the bloom filter case the longlived info is the (initial?) size of
the bloom filter and the number of hash functions. But I still haven't
determined how much it will cost to recalculate them. Right now
they're just hard coded so it doesn't hurt to do it on every rescan
but if it involves peeking at the index reloptions or stats that might
be impractical.



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: BRIN indexes - TRAP: BadArgument
Next
From: Alvaro Herrera
Date:
Subject: Re: BRIN indexes - TRAP: BadArgument