On Fri, Jun 3, 2016 at 3:11 PM, Michael Paquier
<michael.paqu...@gmail.com> wrote:
> On Fri, Jun 3, 2016 at 1:03 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> I wrote:
>>> Jeff Janes <jeff.ja...@gmail.com> writes:
>>>> My biggest gripe with it at the moment is that the signature size should be
>>>> expressed in bits, and then internally rounded up to a multiple of 16,
>>>> rather than having it be expressed in 'uint16'.
>>>> If that were done it would be easier to fix the documentation to be more
>>>> understandable.
>>> +1 ... that sort of definition seems much more future-proof, too.
>>> IMO it's not too late to change this.  (We probably don't want to change
>>> the on-disk representation of the reloptions, but we could convert from
>>> bits to words in bloptions().)
>> There were no objections to this, but also no action.  Attached is a draft
>> patch ... any complaints?
> None. This looks rather sane to me.

Actually, the docs could be more polished. "Limitation" should be
changed to "Limitations", and "Opclass interface" to "Operator Class
Interface". The current wording "Seqscan is slow" is not clear, this
should mention a sequential scan instead. And it is not that slow,
just slower than the heap index scan of bloom..

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to