From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Making hash indexes worthwhile |
Date: | 2009-10-05 06:05:01 |
Message-ID: | f67928030910042305t3e49080cy905beeca9999bf01@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Oct 4, 2009 at 7:13 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
>
>> I've played around a bit with hash indexes, and it seems to me that
>> making them generally worthwhile will take (at least) reducing or
>> entirely doing away with the heavy-wait locks.
>
> Concurrency is really the least of the issues for hash indexes. So far
> it's not clear that they're fast enough even in sequential use ...
Do you know why that should be? I've done some work with gprof, and
the results are pretty suspect, because the total gprof time adds up
to only about 1/3 of the total time the backend spends on CPU
(according to "top"), and I don't know where the unaccounted for time
is going. But a good part of the accounted-for time seems to be
associated with the locking system, even when there is only one active
backend.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2009-10-05 06:50:18 | Re: Rules: A Modest Proposal |
Previous Message | Itagaki Takahiro | 2009-10-05 05:24:14 | Re: Buffer usage in EXPLAIN and pg_stat_statements (review) |