Re: BRIN indexes - TRAP: BadArgument - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: BRIN indexes - TRAP: BadArgument |
Date | |
Msg-id | CA+TgmobqYUvN34fg-8=B5zzSDk9s9uX1oZHSQbnvtg7TN56hxQ@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
|
List | 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
pgsql-hackers by date: