On 07/07/2015 06:28 AM, Marc Mamin wrote:
Sure, but on the other hand, they are so small and quick to build
that they seem to be a good alternative when other index types are too
costly,
even if theses indexes can't deal well with all data ranges passed as query
condition.
Hence it
-Original Message-
From: Josh Berkus [mailto:j...@agliodbs.com]
Sent: Dienstag, 7. Juli 2015 02:04
On 07/06/2015 12:20 AM, Marc Mamin wrote:
There seems to be no fence against useless BRIN indexes that
would allow a fallback on a table scan.
But the time overhead remind
Hello,
First: KUDO !!!
The release notes are extremely promising in regard to performance improvements
:-)
I've made some (dirty) tests with BRIN and btree_gin.
(on a smalll Windows laptop ...)
just a few remarks:
- btree_gin deserve a better description than that:
However, they are
On Mon, Jul 6, 2015 at 12:20 AM, Marc Mamin m.ma...@intershop.de wrote:
Hello,
First: KUDO !!!
The release notes are extremely promising in regard to performance
improvements :-)
I've made some (dirty) tests with BRIN and btree_gin.
(on a smalll Windows laptop ...)
just a few remarks:
On 07/06/2015 12:20 AM, Marc Mamin wrote:
There seems to be no fence against useless BRIN indexes that would allow
a fallback on a table scan.
But the time overhead remind small :)
When have we ever stopped users from creating useless indexes? For one
thing, just because the index
On Tue, Jul 7, 2015 at 9:04 AM, Josh Berkus j...@agliodbs.com wrote:
Are there usage stats in pg_stat_user_indexes for BRIN?
Yes, they are here.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Marc Mamin wrote:
- BRIN cost: I've made a silly test, where all distinct values exist in all
BRIN page ranges:
INSERT into tbrin_1 (cat_id, ) SELECT s%20, ... FROM
generate_series(1,300 )s;
CREATE INDEX cat_brin_1 on tbrin_1 using BRIN (cat_id)with
