On 12/15/2014 07:42 AM, Claudio Freire wrote:
[snip]
If you do that, you start with empty partitions, and each insert
updates the BRIN tuple. Avoiding concurrency loss in this case would
be tricky, but in theory this could allow very general partition
exclusion. In fact it could even work with constraint exclusion right
now: you'd have a single-tuple BRIN index for each partition and
benefit from it. But you don't need to pay the price of updating BRIN
indexes, as min-max tuples for each partition can be produced while
creating the partitions if the syntax already provides the
information. Then, it's just a matter of querying this meta-data which
just happens to have the form of a BRIN tuple for each partition.
Yup. Indeed this is the way I outlined in my previous e-mail.
The only point being: Why bother with BRIN when we already have the
range machinery, and it's trivial to add pointers to partitions from
each range?
I suggested that BRIN would solve a situation when the amount of
partitions is huge (say, thousands) and we might need to be able to
efficiently locate the appropriate partition. In this situation, a
linear search might become prohibitive, or the data structure (a simple
B-Tree, maybe) become too big to be worth keeping in memory. This is
where being able to store the "partition index" on disk would be
interesting.
Moreover, I guess that ---by using this approach
(B-Tree[range]->partition_id and/or BRIN)--- we could efficiently answer
the question "do we have any tuple with this key in some partition?"
which AFAICS is pretty close to us having "global indexes".
Regards,
/ J.L.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
