Re: Minmax indexes - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Minmax indexes
Date
Msg-id CAHGQGwEiSKt4hepOZ7Z9TJxnA_h8m0R-2-Mp-6nGB2dYmOVgBw@mail.gmail.com
Whole thread Raw
In response to Re: Minmax indexes  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Minmax indexes
List pgsql-hackers
On Fri, Aug 15, 2014 at 8:02 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Alvaro Herrera wrote:
>> Heikki Linnakangas wrote:
>
>> > I'm sure this still needs some cleanup, but here's the patch, based
>> > on your v14. Now that I know what this approach looks like, I still
>> > like it much better. The insert and update code is somewhat more
>> > complicated, because you have to be careful to lock the old page,
>> > new page, and revmap page in the right order. But it's not too bad,
>> > and it gets rid of all the complexity in vacuum.
>>
>> It seems there is some issue here, because pageinspect tells me the
>> index is not growing properly for some reason.  minmax_revmap_data gives
>> me this array of TIDs after a bunch of insert/vacuum/delete/ etc:
>
> I fixed this issue, and did a lot more rework and bugfixing.  Here's
> v15, based on v14-heikki2.

I've not read the patch yet. But while testing the feature, I found that

* Brin index cannot be created on CHAR(n) column.  Maybe other data types have the same problem.

* FILLFACTOR cannot be set in brin index.

Are these intentional?

Regards,

-- 
Fujii Masao



pgsql-hackers by date:

Previous
From: Antonin Houska
Date:
Subject: Another logical decoding assertion failure
Next
From: Andres Freund
Date:
Subject: Re: Another logical decoding assertion failure