Skip site navigation (1) Skip section navigation (2)

Re: New data type: uniqueidentifier

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Dmitry G(dot) Mastrukov" <dmitry(at)taurussoft(dot)org>
Cc: "Alex Pilosov" <alex(at)pilosoft(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: New data type: uniqueidentifier
Date: 2001-06-28 15:12:48
Message-ID: 24320.993741168@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
"Dmitry G. Mastrukov" <dmitry(at)taurussoft(dot)org> writes:
> Alex Pilosov <alex(at)pilosoft(dot)com> wrote:
>> On Tue, 26 Jun 2001, Dmitry G. Mastrukov wrote:
> I've marked "=" operator with HASH clause (and planner has started to
> use
> hash jons). But as I understand the right way is to create special hash
> function (may be wrapper for hash_any(), isn't it?) and register it for
> hash
> as for btree method.
>> 
>> No. Currently, there's no way to specify a hash function for a given
>> operator, it always uses a builtin function that operates on memory
>> representation of a value.

> Strange. When I execute following query (slightly modified query from User's
> Guide chapter 7.6)

You're looking at support for hash indexes, which have nothing to do
with hash joins.

*Why* they have nothing to do with hash joins, I dunno.  You'd think
that using the same hash functions for both would be a good idea.
But that's not how it's set up at the moment.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: John MooreDate: 2001-06-28 15:33:45
Subject: Re: Backup and Recovery
Previous:From: Ilan FaitDate: 2001-06-28 15:11:45
Subject: how to monitor/examine the database

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group