| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
| Cc: | Neil Conway <neilc(at)samurai(dot)com>, Christopher Petrilli <petrilli(at)gmail(dot)com>, Ying Lu <ying_lu(at)cs(dot)concordia(dot)ca>, pgsql-general(at)postgresql(dot)org, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL |
| Date: | 2005-05-10 15:49:50 |
| Message-ID: | 594.1115740190@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-performance |
"Jim C. Nasby" <decibel(at)decibel(dot)org> writes:
> What's the challange to making it adaptive, comming up with an algorithm
> that gives you the optimal bucket size (which I would think there's
> research on...) or allowing the index to accommodate different bucket
> sizes existing in the index at once? (Presumably you don't want to
> re-write the entire index every time it looks like a different bucket
> size would help.)
Exactly. That's (a) expensive and (b) really hard to fit into the WAL
paradigm --- I think we could only handle it as a REINDEX. So if it
were adaptive at all I think we'd have to support multiple bucket sizes
existing simultaneously in the index, and I do not see a good way to do
that.
Allowing a bucket size to be specified at CREATE INDEX doesn't seem out
of line though. We'd have to think up a scheme for index-AM-specific
index parameters ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim C. Nasby | 2005-05-10 16:11:22 | Re: Trigger that spawns forked process |
| Previous Message | Madeleine Theile | 2005-05-10 15:44:49 | alter table owner doesn't update acl information |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim C. Nasby | 2005-05-10 17:26:52 | Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL |
| Previous Message | John A Meinel | 2005-05-10 15:46:54 | Re: Partitioning / Clustering |