| From: | "Joel Jacobson" <joel(at)compiler(dot)org> |
|---|---|
| To: | pgsql-hackers(at)lists(dot)postgresql(dot)org, "Tomas Vondra" <tomas(dot)vondra(at)enterprisedb(dot)com>, "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "jian he" <jian(dot)universality(at)gmail(dot)com> |
| Subject: | Re: Do we want a hashset type? |
| Date: | 2023-06-13 18:50:50 |
| Message-ID: | 605bfc3d-9e67-46d2-ab06-8e3459e62e25@app.fastmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jun 12, 2023, at 22:36, Joel Jacobson wrote:
> On Mon, Jun 12, 2023, at 21:58, Tomas Vondra wrote:
>> My suggestion is to be lazy, just use the lookup3 we have in hashfn.c
>> (through hash_bytes or something), and at the same time make it possible
>> to switch to a different function in the future. I'd store and ID of the
>> hash function in the set, so that we can support a different algorithm
>> in the future, if we choose to.
hashset is now using hash_bytes_uint32() from hashfn.h
Other changes in the same commit:
* Introduce hashfn_id field to specify hash function ID
* Implement hashset_send and hashset_recv and add C-test using libpq
* Add operators and operator classes for hashset comparison, sorting
and distinct queries
Looks good? If so, I wonder what's best to focus on next?
Perhaps adding support for bigint? Other ideas?
/Joel
| Attachment | Content-Type | Size |
|---|---|---|
| hashset-0.0.1-da3b024.patch | application/octet-stream | 25.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2023-06-13 18:55:19 | Re: Add wait event for log emission? |
| Previous Message | Noah Misch | 2023-06-13 18:29:20 | Re: pgsql: Fix search_path to a safe value during maintenance operations. |