Re: 9.5 alpha: some small comments on BRIN and btree_gin

From: Marc Mamin <M(dot)Mamin(at)intershop(dot)de>
To: "'Josh Berkus'" <josh(at)agliodbs(dot)com>, "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 9.5 alpha: some small comments on BRIN and btree_gin
Date: 2015-07-07 13:28:18
Message-ID: B6F6FD62F2624C4C9916AC0175D56D8828BF0D05@jenmbs01.ad.intershop.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Message-----
> From: Josh Berkus [mailto:josh(at)agliodbs(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2015-07-07 13:31:55 Re: FPW compression leaks information
Previous Message Oskari Saarenmaa 2015-07-07 13:23:48 Re: Repeated pg_upgrade buildfarm failures on binturon