Insight into indexes? (or inverting then externally) - Mailing list pgsql-general

From Joshua b. Jore
Subject Insight into indexes? (or inverting then externally)
Date
Msg-id Pine.BSO.4.44.0206050857450.17988-100000@kitten.greentechnologist.org
Whole thread Raw
Responses Re: Insight into indexes? (or inverting then externally)  (Oleg Bartunov <oleg@sai.msu.su>)
Re: Insight into indexes? (or inverting then externally)  (Neil Conway <nconway@klamath.dyndns.org>)
List pgsql-general
So far as I can tell indexes in PostgreSQL are fairly opaque things. The
planner may or may not decide to use them, exactly what they contain is
largely unknown (unless I want to read the source), how PostgreSQL uses
them and in which cases a btree index is better than a hash index.

Foo. If I've managed to just skip over a manual section please whack me
with a 2x4. If I haven't then any links would be appreciated. I'm
considering how best to provide a fast index on a 2.5 million row table
(all the voters in Minnesota). Since I can't see what PostgreSQL is doing
with the indexes I have to wonder if I can eke out some more performance
by just indexing the record's id numbers (a usually numeric char(10) -
blame the MN Secretary of State for the "mostly" part) in PostgreSQL and
then sticking an inverted index into say... BerkeleyDB.

Records might look like where it's obvious that the ids store nicely..

lname.db
'Jore' => '12345678901234567890'

So before I jump down this rabbit hole is there anything I can do to
PostgreSQL to see what is in the indexes and if there is any way to tweak
them? And when is a hash index preferrable to a btree index? Or that other
index type that I don't remember the name of.

Joshua b. Jore ; http://www.greentechnologist.org ; 1121 1233 1311 200
1201 1302 1211 200 1201 1303 200 1300 1233 1313 1211 1302 1212 1311 1230
200 1201 1303 200 1321 1233 1311 1302 200 1211 1232 1211 1231 1321 200
1310 1220 1221 1232 1223 1303 200 1321 1233 1311 200 1201 1302 1211 232
200 1112 1233 1310 1211 200 1013 1302 1211 1211 1232 201 22


pgsql-general by date:

Previous
From: "Nick Fankhauser"
Date:
Subject: Re: Postgres 7.2.1 Really Spinning the CPU
Next
From: Stephan Szabo
Date:
Subject: Re: DEFERRABLE and DEFERRED