Re: new index type with clustering in mind. - Mailing list pgsql-general

From Jack Douglas
Subject Re: new index type with clustering in mind.
Date
Msg-id 013501d014ae$2ce62650$86b272f0$@douglastechnology.co.uk
Whole thread Raw
In response to Re: new index type with clustering in mind.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: new index type with clustering in mind.  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-general
> in 9.4, GIN indexes are pretty close to this already

Do I understand correctly that BRIN indexes will be even closer to this?

Kindest regards
Jack

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: 24 May 2014 22:46
To: Martijn van Oosterhout
Cc: Jack Douglas; pgsql-general@postgresql.org
Subject: Re: [GENERAL] new index type with clustering in mind.

Martijn van Oosterhout <kleptog@svana.org> writes:
> On Sat, May 24, 2014 at 05:58:37PM +0100, Jack Douglas wrote:
>> Would the following be practical to implement:
>> A btree-like index type that points to *pages* rather than individual
rows.

> It's an interesting idea, but, how can you *ever* delete index entries?
> I.e. is there a way to maintain the index without rebuilding it
> regularly?

The discussions at PGCon pointed out that with the posting-list compression
logic added in 9.4, GIN indexes are pretty close to this already.  Multiple
items on the same heap page will typically only take one byte of index space
per item; but there is an identifiable entry, so you don't get into these
questions of when VACUUM should remove entries, and it's not lossy so you're
not forced to pay the overhead of rechecking every entry on the linked-to
page.

Not to say that 9.4 GIN is necessarily the last word on the subject, but it
would be worth testing it out before deciding that we need something better.
(beta1 is out.  It needs testing.  Hint hint.)

            regards, tom lane



pgsql-general by date:

Previous
From: Gabriel Sánchez Martínez
Date:
Subject: Re: invalid memory alloc request size
Next
From: Merlin Moncure
Date:
Subject: Re: Use cases for lateral that do not involve a set returning function