| From: | pgsql(at)mohawksoft(dot)com |
|---|---|
| To: | "Hannu Krosing" <hannu(at)tm(dot)ee> |
| Cc: | pgsql(at)mohawksoft(dot)com, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Victor Y(dot) Yegorov" <viy(at)mits(dot)lv>, "Pg Hackers" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: bitmap AM design |
| Date: | 2005-03-03 16:41:20 |
| Message-ID: | 16831.24.91.171.78.1109868080.squirrel@mail.mohawksoft.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> Ühel kenal päeval (teisipäev, 1. märts 2005, 14:54-0500), kirjutas
> pgsql(at)mohawksoft(dot)com:
>> Now, it occurs to me that if my document reference table can refer to
>> something other than an indexed primary key, I can save a lot of index
>> processing time in PostgreSQL if I can have a "safe" analogy to CTID.
>
> I guess you could work on making hash indexes better (for concurrent
> access).
>
> 'a "safe" analogy to CTID' looks remarkably like hash index
>
Yes, I agree, but I don't particularly like linear hash models without the
ability to adjust the initial table size estimates. Also, hash tables
without access to the hash function typically have a lot of collision,
specifically, I am dubious of "generic" hash functions having an optimally
dispersed behavior.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joachim Wieland | 2005-03-03 16:41:36 | plperl function has side-effects |
| Previous Message | pgsql | 2005-03-03 16:23:55 | Re: cluster table by two-column index ? |