Hi
>> I thought hash indexes were discouraged over btree. Anyway, I'll test it.
>
> Absolutely. You do not want to be using Hash Indexes these days - stick with
> B-Tree. The hash refers to the method by which the executor matches the two
> column fields and is not related to the underlying index
On Tue, Feb 8, 2011 at 12:42 PM, Mark Cave-Ayland
wrote:
> On 08/02/11 11:05, Jorge Arévalo wrote:
>
>> 2011/2/8 Stefan Keller:
>>>
>>> " Hash Cond: (TABLE_C.STR_FIELD = TABLE_B.STR_FIELD)"
>>> tells me that these two longish strings are compared first.
>>> Did you already try to index TABLE_C.ST
On 08/02/11 11:05, Jorge Arévalo wrote:
2011/2/8 Stefan Keller:
" Hash Cond: (TABLE_C.STR_FIELD = TABLE_B.STR_FIELD)"
tells me that these two longish strings are compared first.
Did you already try to index TABLE_C.STR_FIELD and TABLE_B.STR_FIELD
as hash instead btree?
I thought hash indexes
Hi,
2011/2/8 Stefan Keller :
> " Hash Cond: (TABLE_C.STR_FIELD = TABLE_B.STR_FIELD)"
> tells me that these two longish strings are compared first.
> Did you already try to index TABLE_C.STR_FIELD and TABLE_B.STR_FIELD
> as hash instead btree?
I thought hash indexes were discouraged over btree. A
More possibilities (just ideas) before update:
* VACUUM FULL and reindex after that. If not, your indexes became bloated.
* If you've got the RAM, just use more of it, 1 or 2 GB. You can do
this at runtime: SET maintenance_work_mem="180MB". If you can fit
whole tables into memory, reindexing shoul
" Hash Cond: (TABLE_C.STR_FIELD = TABLE_B.STR_FIELD)"
tells me that these two longish strings are compared first.
Did you already try to index TABLE_C.STR_FIELD and TABLE_B.STR_FIELD
as hash instead btree?
Did you set autovacuum off during update? transaction level?
Yours, S.
2011/2/7 Jorge Arév
