Re: Index AM change proposals, redux

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Index AM change proposals, redux
Date: 2008-04-24 10:59:37
Message-ID: 1209034777.4259.1486.camel@ebony.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2008-04-23 at 19:43 -0700, Ron Mayer wrote:
> Tom Lane wrote:
> > Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> >> On Wed, 2008-04-23 at 12:07 -0400, Tom Lane wrote:
> >>> To be acceptable, a GIT patch would have to be optional and it
> >>> ...
> > I was considering a new pg_index column. Or else we'd have to fix
> > the storage-parameter infrastructure to support restricting changes
> > of some parameters.
>
>
> Interesting. Does this mean that down the road a postgis index
> might be GIT-ified?

Yes, all types of index can benefit from some form of compression. The
only issue is that there isn't one technique that covers all use cases,
so it will take time and we should be careful to do the most important
ones first.

> On my biggest tables (clustered by zip/postal code) the index on
> the geometry column with a postgis index probably sees all the
> rows on each of it's pages pointing to the same few heap pages.
> If I understand right, that's the kind of pattern that GIT helps.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2008-04-24 11:13:09 Re: Index AM change proposals, redux
Previous Message Richard Huxton 2008-04-24 09:13:55 Re: I think this is a BUG?