Re: Index AM change proposals, redux

From: Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, 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-14 13:15:43
Message-ID: 480358FF.2010209@cheapcomplexdevices.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas wrote:
> Ron Mayer wrote:
>> One use case that I think GIT would help a lot with are my
>> large address tables that are clustered by zip-code but
>> often queried by State, City, County, School District,
>> Police Beat, etc.
>
>> I imagine a GIT index on "state" would just occupy
>> a couple pages at most regardless of how large the
>> table gets.
>
> .. Not quite that much, though. GIT still stores one index pointer per
> heap page even on a fully clustered table. Otherwise it's not much good
> for searches.

Then I wonder if I can conceive of yet another related
index type that'd be useful for such clustered tables. If
I had something like GIT that stored something like
"values State='CA' can be found on pages 1000 through 10000
and 20000 through 21000" would it be even more effective on
such a table than GIT?

If so, it seems it'd give many advantages that partitioning
by state could give (at least for querying).

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2008-04-14 13:36:58 Re: Cached Query Plans (was: global prepared statements)
Previous Message Alexander Wöhrer 2008-04-14 12:56:51 Re: [Pljava-dev] stack depth limit exceeded - patch possible?