Ravi Kiran writes:
> From the above two cases, I am understanding that even even when the hash
> function is made to return a constant, The hashjoin agorithm is taking
> significantly lower time compared to nested loop.
> Could anyone explain why does the hashjoin algorithm takes significantly
>
Hi,
As part part of my project, I had to compare the time taken by the Hashjoin
algorithm to that of Nested loop algorithm for the inner join and Natural
join queries, under two cases. I used six tables to join each other each
containing 5000 rows each approximately.
The two cases are given bel
On 1/24/15 9:03 AM, Adrian Klaver wrote:
On 01/23/2015 10:42 PM, Ravi Kiran wrote:
hi,
I want to know what kind of hash function postgresql uses while joining.
I was debugging through gdb, I found out that it is not using bob
jenkins hash function but a different hash function *hash_uint32() a
On 01/23/2015 10:42 PM, Ravi Kiran wrote:
hi,
I want to know what kind of hash function postgresql uses while joining.
I was debugging through gdb, I found out that it is not using bob
jenkins hash function but a different hash function *hash_uint32() and
hash_any() *functions if the joining at
hi,
I want to know what kind of hash function postgresql uses while joining. I
was debugging through gdb, I found out that it is not using bob jenkins
hash function but a different hash function *hash_uint32() and
hash_any() *functions
if the joining attribute is an integer, and a different kind
kolanpaka.ravikiran wrote
> Hi,
>
> I want to know what kind of hash function postgres is using currently, can
> someone please explain the algorithm postgres is using for the hash
> function in the hash join algorithm.
>
> Thanks,
>
> K.Ravikiran
Would you please just pick one of the mailing l
Hi,
I want to know what kind of hash function postgres is using currently, can
someone please explain the algorithm postgres is using for the hash
function in the hash join algorithm.
Thanks,
K.Ravikiran
On Tue, Jun 14, 2005 at 15:54:50 -0500,
Peter Fein <[EMAIL PROTECTED]> wrote:
>
> I'm unclear why I'd need to store the hash in a column. I suppose I
> could have the hash column populated by a trigger on inserts, but this
> seems to get me the same functionality & is less obvious.
>
> For the
Bruno Wolff III wrote:
> On Tue, Jun 14, 2005 at 08:33:34 -0500,
> Peter Fein <[EMAIL PROTECTED]> wrote:
>
>>Knowing the specifics of the data I'm putting in sometext, a halfway
>>decent hash function would make collisions so rare as to make the chance
>>insignificant (and collisions wouldn't br
On Tue, Jun 14, 2005 at 08:33:34 -0500,
Peter Fein <[EMAIL PROTECTED]> wrote:
>
> Knowing the specifics of the data I'm putting in sometext, a halfway
> decent hash function would make collisions so rare as to make the chance
> insignificant (and collisions wouldn't break anything anyway). Is th
--- Greg Stark <[EMAIL PROTECTED]> wrote:
>
> Note that MD5 is slow and CPU-intensive. By design.
>
> If you want a quick way to find matching records then you might find
> something
> like CRC to be more useful. With MD5 it's supposed to be hard for
> someone to
> come up with inputs that hash t
On 14 Jun 2005, at 14:33, Peter Fein wrote:
Alex Stapleton wrote:
On 13 Jun 2005, at 23:49, Peter Fein wrote:
Hi-
I wanted to use a partially unique index (dependent on a flag) on
a TEXT
column, but the index row size was too big for btrees. See the
thread
"index row size 2728 exc
Alex Stapleton wrote:
>
> On 13 Jun 2005, at 23:49, Peter Fein wrote:
>
>
>> Hi-
>>
>> I wanted to use a partially unique index (dependent on a flag) on a TEXT
>> column, but the index row size was too big for btrees. See the thread
>> "index row size 2728 exceeds btree maximum, 2713" from the
On 13 Jun 2005, at 23:49, Peter Fein wrote:
Hi-
I wanted to use a partially unique index (dependent on a flag) on a
TEXT
column, but the index row size was too big for btrees. See the thread
"index row size 2728 exceeds btree maximum, 2713" from the
beginning of
this month for someone w
Am Dienstag, den 14.06.2005, 02:40 -0400 schrieb Greg Stark:
> Shelby Cain <[EMAIL PROTECTED]> writes:
>
> > > My question is: is the builtin MD5 appropriate for this use or should I be
> > > using a function from pl/something? Figures on collision rates would be
> > > nice as well - the typical c
Shelby Cain <[EMAIL PROTECTED]> writes:
> > My question is: is the builtin MD5 appropriate for this use or should I be
> > using a function from pl/something? Figures on collision rates would be
> > nice as well - the typical chunk of text is probably 1k-8k.
Note that MD5 is slow and CPU-intensiv
--- Peter Fein <[EMAIL PROTECTED]> wrote:
> Hi-
>
> I wanted to use a partially unique index (dependent on a flag) on a
> TEXT
> column, but the index row size was too big for btrees. See the
> thread
> "index row size 2728 exceeds btree maximum, 2713" from the beginning
> of
> this month for so
Hi-
I wanted to use a partially unique index (dependent on a flag) on a TEXT
column, but the index row size was too big for btrees. See the thread
"index row size 2728 exceeds btree maximum, 2713" from the beginning of
this month for someone with a similar problem. In it, someone suggests
indexi
18 matches
Mail list logo
