Re: WIP: BRIN multi-range indexes
От | John Naylor |
---|---|
Тема | Re: WIP: BRIN multi-range indexes |
Дата | |
Msg-id | CAFBsxsFbsFHNukFCb+_x+a0UmeivnTa5XHLzCrcAEWx_X_B26A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP: BRIN multi-range indexes (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
Ответы |
Re: WIP: BRIN multi-range indexes
|
Список | pgsql-hackers |
Hi Tomas,
I took another look through the Bloom opclass portion (0004) with sorted_mode omitted, and it looks good to me code-wise. I think this part is close to commit-ready. I also did one more proofreading pass for minor details.
+ rows per block). The default values is <literal>-0.1</literal>, and
+ greater than 0.0 and smaller than 1.0. The default values is 0.01,
s/values/value/
+ * bloom filter, we can easily and cheaply test wheter it contains values
s/wheter/whether/
+ * XXX We assume the bloom filters have the same parameters fow now. In the
s/fow/for/
+ * or null if it does not exists.
s/exists/exist/
+ * We do expect the bloom filter to eventually switch to hashing mode,
+ * and it's bound to be almost perfectly random, so not compressible.
Leftover from when it started out in sorted mode.
+ if ((m/8) > BLCKSZ)
It seems we need something more safe, to account for page header and tuple header at least. As the comment before says, the filter will eventually not be compressible. I remember we can't be exact here, with the possibility of multiple columns, but we can leave a little slack space.
-- + rows per block). The default values is <literal>-0.1</literal>, and
+ greater than 0.0 and smaller than 1.0. The default values is 0.01,
s/values/value/
+ * bloom filter, we can easily and cheaply test wheter it contains values
s/wheter/whether/
+ * XXX We assume the bloom filters have the same parameters fow now. In the
s/fow/for/
+ * or null if it does not exists.
s/exists/exist/
+ * We do expect the bloom filter to eventually switch to hashing mode,
+ * and it's bound to be almost perfectly random, so not compressible.
Leftover from when it started out in sorted mode.
+ if ((m/8) > BLCKSZ)
It seems we need something more safe, to account for page header and tuple header at least. As the comment before says, the filter will eventually not be compressible. I remember we can't be exact here, with the possibility of multiple columns, but we can leave a little slack space.
В списке pgsql-hackers по дате отправления: