Re: Hashable custom types
| От | Tom Lane |
|---|---|
| Тема | Re: Hashable custom types |
| Дата | |
| Msg-id | 21237.1398524193@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Hashable custom types (David Fetter <david@fetter.org>) |
| Ответы |
Re: Hashable custom types
|
| Список | pgsql-hackers |
David Fetter <david@fetter.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
В списке pgsql-hackers по дате отправления: