Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> [blink] This seems to miss out on the actual point of the thread (hash
> >> bucket size shouldn't be a disk page) in favor of an entirely
> >> unsupported sub-suggestion.
>
> > Yes, I was unsure of the text mysel
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> [blink] This seems to miss out on the actual point of the thread (hash
>> bucket size shouldn't be a disk page) in favor of an entirely
>> unsupported sub-suggestion.
> Yes, I was unsure of the text myself. I have changed it to:
>
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Added to TODO:
> > * Order heap pointers on hash index pages by hash value and ctid
>
> [blink] This seems to miss out on the actual point of the thread (hash
> bucket size shouldn't be a disk page) in favor of an entirely
> unsu
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Added to TODO:
> * Order heap pointers on hash index pages by hash value and ctid
[blink] This seems to miss out on the actual point of the thread (hash
bucket size shouldn't be a disk page) in favor of an entirely
unsupported sub-suggestion.
Added to TODO:
* Order heap pointers on hash index pages by hash value and ctid
---
Zeugswetter Andreas SB SD wrote:
>
> > We could safely sort on the hash value, but I'm not sure how effective
> > that would be, c
> We could safely sort on the hash value, but I'm not sure how effective
> that would be, considering that we're talking about values that already
> hashed into the same bucket --- there's likely not to be very many
> distinct hash values there.
I think we can safely put that on the todo list.
Th
> Sailesh Krishnamurthy <[EMAIL PROTECTED]> writes:
>> This is probably a crazy idea, but is it possible to organize the data
>> in a page of a hash bucket as a binary tree ?
>
> Only if you want to require a hash opclass to supply ordering operators,
> which sort of defeats the purpose I think. H
Jeff Davis <[EMAIL PROTECTED]> writes:
> On Sat, 2004-06-05 at 13:31, Tom Lane wrote:
>> Only if you want to require a hash opclass to supply ordering operators,
>> which sort of defeats the purpose I think. Hash is only supposed to
>> need equality not ordering.
> Is it possible to assume some k
On Sat, 2004-06-05 at 13:31, Tom Lane wrote:
> Only if you want to require a hash opclass to supply ordering operators,
> which sort of defeats the purpose I think. Hash is only supposed to
> need equality not ordering.
Is it possible to assume some kind of ordering (i.e. strcmp() the binary
data
Sailesh Krishnamurthy <[EMAIL PROTECTED]> writes:
> This is probably a crazy idea, but is it possible to organize the data
> in a page of a hash bucket as a binary tree ?
Only if you want to require a hash opclass to supply ordering operators,
which sort of defeats the purpose I think. Hash is on
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> This means that if you have only one or a few items per
Tom> bucket, the information density is awful, and you lose big on
Tom> I/O requirements compared to a btree index. On the other
Tom> hand, if you have enough items per
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> There seems to be something seriously defective with hash indexes in old
> versions of PostgreSQL.
They still suck; I'm not aware of any situation where I'd recommend hash
over btree indexes in Postgres. I think we have fixed the hash indexes'
deadlock
12 matches
Mail list logo
