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

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Marc Mamin <M(dot)Mamin(at)intershop(dot)de>
Cc: "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-06 18:11:48
Message-ID: CAMkU=1yrq3JV7Xdqb1ChMBwXyrqpr1q00R6kYcn_-LmagJBOqg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 6, 2015 at 12:20 AM, Marc Mamin <M(dot)Mamin(at)intershop(dot)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:
>
>
> - btree_gin deserve a better description than that:
>
> "However, they are useful for GIN testing and as a base for developing
> other GIN operator classes."
>
> I came to similar times between btree and gin for indexes on "category"
> columns (ca 20 to 200 distinct values)
> For me, gin clearly wins here thanks to the index size difference.
>

I reached the same conclusion for things with higher distinct values, but
still several copies of each distinct value. except I don't think we should
change the description until the BETWEEN issue is resolved. That is a
pretty serious limitation, I think.

Or at least, if you we invite people to use it for this purpose, we would
have to warn them that it is not suitable for range queries. It wouldn't
be so bad if it merely didn't support them well, but as things are now it
positively pulls the planner away from better options, because it looks
falsely attractive.

I've looked into doing myself, but I'm afraid it is beyond me.

Cheers,

Jeff

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2015-07-06 19:19:14 Re: Fix broken Install.bat when target directory contains a space
Previous Message Josh Berkus 2015-07-06 17:56:07 Re: Support for N synchronous standby servers - take 2