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).
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? |