| From: | Neil Conway <neilc(at)samurai(dot)com> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: hash index work |
| Date: | 2005-05-28 13:14:38 |
| Message-ID: | 42986EBE.4070904@samurai.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
Bruce Momjian wrote:
> Neil, I have added these item to the TODO list. Do you plan on applying
> this?
No, I don't have any immediate plans to apply it, as unfortunately I
didn't see a performance win :-( It's also possible I'm just not
measuring the right workload, although I don't have time to rerun the
benchmarks at the moment.
The patch does two things: (1) change hash indexes to only store the
key's hash value, not the entire key (2) store index elements within a
hash bucket in order of hash key and search for matches via binary
search. #1 is definitely a win in some in some circumstances (e.g.
indexing large fields or types with expensive equality operators), but
those aren't the common case. I'm surprised that #2 is not a more
noticeable improvement...
One possibility would be to provide an optional implementation of #1,
perhaps via an alternate index operator class. That way people could
select it in those situations in which it is worth using.
-Neil
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Treat | 2005-05-28 14:23:37 | Re: psql backslash consistency |
| Previous Message | Tom Lane | 2005-05-28 04:14:18 | Re: [HACKERS] Fix PID file location? |