Re: 9.5 alpha: some small comments on BRIN and btree_gin - Mailing list pgsql-hackers

From Marc Mamin
Subject Re: 9.5 alpha: some small comments on BRIN and btree_gin
Date
Msg-id B6F6FD62F2624C4C9916AC0175D56D8828BF0D05@jenmbs01.ad.intershop.net
Whole thread Raw
In response to Re: 9.5 alpha: some small comments on BRIN and btree_gin  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers

> -----Original Message-----
> From: Josh Berkus [mailto:josh@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 small :)
> 
> When have we ever stopped users from creating useless indexes?  

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 would be fine if the planner could reject these indexes in the bad cases.

I don't mean this is something I'm counting on, but it could be a good idea to mention this limitation in the doc.

regards,

Marc Mamin


> For one
> thing, just because the index isn't useful *now* doesn't mean it won't
> be in the future.
> 
> Now, it would be useful to have a brin_index_effectiveness() function
> so that DBAs could check for themselves whether they should dump
> indexes.
> However, I don't see needing that for 9.5.
> 
> Are there usage stats in pg_stat_user_indexes for BRIN?
> 
> --
> Josh Berkus
> PostgreSQL Experts Inc.
> http://pgexperts.com

pgsql-hackers by date:

Previous
From: Oskari Saarenmaa
Date:
Subject: Re: Repeated pg_upgrade buildfarm failures on binturon
Next
From: Stephen Frost
Date:
Subject: Re: FPW compression leaks information