Re: BRIN indexes - TRAP: BadArgument

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Erik Rijkers <er(at)xs4all(dot)nl>, Emanuel Calvo <3manuek(at)esdebian(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)com>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BRIN indexes - TRAP: BadArgument
Date: 2014-10-30 17:56:22
Message-ID: CA+TgmobqYUvN34fg-8=B5zzSDk9s9uX1oZHSQbnvtg7TN56hxQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

+ <acronym>BRIN</acronym> indexes can satisfy queries via the bitmap
+ scanning facility, and will return all tuples in all pages within

"The bitmap scanning facility?" Does this mean a bitmap index scan?
Or something novel to BRIN? I think this could be clearer.

+ This enables them to work as very fast sequential scan helpers to avoid
+ scanning blocks that are known not to contain matching tuples.

Hmm, but they don't actually do anything about sequential scans per
se, right? I'd say something like: "Because a BRIN index is very
small, scanning the index adds little overhead compared to a
sequential scan, but may avoid scanning large parts of the table that
are known not to contain matching tuples."

+ depend on the operator class selected for the data type.

The operator class is selected for the index, not the data type.

+ The size of the block range is determined at index creation time with
+ the <literal>pages_per_range</> storage parameter.
+ The smaller the number, the larger the index becomes (because of the need to
+ store more index entries), but at the same time the summary data stored can
+ be more precise and more data blocks can be skipped during an index scan.

I would insert a sentence something like this: "The number of index
entries will be equal to the size of the relation in pages divided by
the selected value for pages_per_range. Therefore, the smaller the
number...." At least, I would insert that if it's actually true. My
point is that I think the effect of pages_per_range could be made more
clear.

+ The core <productname>PostgreSQL</productname> distribution includes
+ includes the <acronym>BRIN</acronym> operator classes shown in
+ <xref linkend="gin-builtin-opclasses-table">.

Shouldn't that say brin, not gin?

+ requiring the access method implementer only to implement the semantics

The naming of the reverse range map seems a little weird. It seems
like most operations go through it, so it feels more like the forward
direction. Maybe I'm misunderstanding. (I doubt it's worth renaming
it at this point either way, but I thought I'd mention it.)

+ errmsg("unlogged BRIN indexes are not supported")));

Why not? Shouldn't be particularly hard, I wouldn't think.

I'm pretty sure you need to create a pageinspect--1.3.sql, not just
update the 1.2 file. Because that's in 9.4, and this won't be.

I'm pretty excited about this feature. I think it's going to be very
good for PostgreSQL.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Adam Brightwell 2014-10-30 18:24:14 Re: alter user/role CURRENT_USER
Previous Message Heikki Linnakangas 2014-10-30 17:52:47 Re: WAL format and API changes (9.5)