From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Deprecating Hash Indexes |
Date: | 2012-10-15 17:07:03 |
Message-ID: | CA+TgmobGgvSP_a9n3Xn=ZNeqrZQAov+af4vYjO2QjjBk_xUocg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 15, 2012 at 12:59 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> I don't think I'd go so far as to say that we should
>> imply that they'll be removed in a future release. Given how deeply
>> intertwined they are with the planner, I doubt that that will happen;
>> and I think there is enough interest in the technology that it's
>> likely to eventually be fixed.
>
> Hash indexes aren't used in the planner. Hash joins use completely
> separate code.
It's not really completely separate, because to do a hash join we have
to find a hash function for the relevant data types, and IIUC we do
that by looking up the default hash opclass for the datatype and
finding its first support function. Of course, if we were to remove
the hash AM, then you couldn't define a hash opclass against it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Farina | 2012-10-15 17:10:53 | Re: Hash id in pg_stat_statements |
Previous Message | Simon Riggs | 2012-10-15 17:03:35 | Re: Deprecating Hash Indexes |