Re: Hashable custom types

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Fetter <david(at)fetter(dot)org>
Cc: Paul Ramsey <pramsey(at)cleverelephant(dot)ca>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hashable custom types
Date: 2014-04-26 14:56:33
Message-ID: 21237.1398524193@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Fetter <david(at)fetter(dot)org> writes:
> On Fri, Apr 25, 2014 at 04:47:49PM -0700, Paul Ramsey wrote:
>> ERROR: could not implement recursive UNION
>> DETAIL: All column datatypes must be hashable.

> This leads to an interesting question, which is why does our
> implementation require this. I'm guessing it's a performance
> optimization.

Well, you clearly need to have a notion of equality for each column
datatype, or else UNION doesn't mean anything.

In general we consider that a datatype's notion of equality can
be defined either by its default btree opclass (which supports
sort-based query algorithms) or by its default hash opclass
(which supports hash-based query algorithms).

The plain UNION code supports either sorting or hashing, but
we've not gotten around to supporting a sort-based approach
to recursive UNION. I'm not convinced that it's worth doing ...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-04-26 15:05:46 Re: includedir_internal headers are not self-contained
Previous Message Andres Freund 2014-04-26 13:19:52 Re: Decrease MAX_BACKENDS to 2^16