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
> -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 overh
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
On Tue, Jul 7, 2015 at 9:04 AM, Josh Berkus 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:
http://www.postgresql.org/mailpref/pgsql-hack
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 Mon, Jul 6, 2015 at 12:20 AM, Marc Mamin 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:
>
>
> - bt
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 use
