Re: ToDo list update for BRIN indexes

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ToDo list update for BRIN indexes
Date: 2015-12-21 14:38:26
Message-ID: CA+TgmoZg=fMEfXt2+rKX9qrBJfet6C_-zkK1eVAEy=jxCM+CtQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 21, 2015 at 8:06 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 21 December 2015 at 12:54, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>
>> On Thu, Jul 9, 2015 at 4:49 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>> > Is there anything in the below section which has been been implemented
>> > or
>> > rendered irrelevant by BRIN indexes?
>> >
>> > https://wiki.postgresql.org/wiki/Todo#Indexes
>> >
>> > "Consider smaller indexes that record a range of values per heap page,
>> > rather than having one index entry for every heap row"
>>
>> [ catching up on old threads ]
>>
>> BRIN is exactly this, isn't it? Well, moreso: it's a range of values
>> for a range of heap pages.
>
> It's close, but not the same.
>
> BRIN is a summary index and so could never support uniqueness.

Hmm, but that Todo wording seems to suggest a summary index, so I
don't think that proposal would support uniqueness either.

> It's also possible to have an index type that has a precise TID entry, yet a
> more compact format, which would then allow unique values. This would be
> similar to the way SQLServer compresses primary key indexes.

True. But would that require a new index type, or would we do that
just by optimizing btree?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2015-12-21 14:40:40 Re: Patch to improve a few appendStringInfo* calls
Previous Message Tom Lane 2015-12-21 14:36:59 Re: Experimental evaluation of PostgreSQL's query optimizer