From: | Tom Dunstan <pgsql(at)tomd(dot)cc> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Joel Jacobson <joel(at)compiler(dot)org>, jian he <jian(dot)universality(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Do we want a hashset type? |
Date: | 2023-06-14 04:31:09 |
Message-ID: | CAPPfruxMELrBtq9XCJ6VNd9W7rLbJ1E3CV8yP+k-EZkbgBPhyg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 12 Jun 2023 at 22:37, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
wrote:
> Perhaps. So you're proposing to have this as a regular built-in type?
> It's hard for me to judge how popular this feature would be, but I guess
> people often use arrays while they actually want set semantics ...
>
Perspective from a potential user: I'm currently working on something where
an array-like structure with fast membership test performance would be very
useful. The main type of query is doing an =ANY(the set) filter, where the
set could contain anywhere from very few to thousands of entries (ints in
our case). So we'd want the same index usage as =ANY(array) but would like
faster row checking than we get with an array when other indexes are used.
Our app runs connecting to either an embedded postgres database that we
control or an external one controlled by customers - this is typically RDS
or some other cloud vendor's DB. Having such a type as a separate extension
would make it unusable for us until all relevant cloud vendors decided that
it was popular enough to include - something that may never happen, or even
if it did, now any time soon.
Cheers
Tom
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2023-06-14 04:31:33 | Re: Fix a typo in md.c |
Previous Message | Amit Kapila | 2023-06-14 04:17:24 | Re: [DOC] Update ALTER SUBSCRIPTION documentation v3 |