| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Why do indexes and sorts use the database collation? |
| Date: | 2023-11-14 16:15:49 |
| Message-ID: | c46e94e0-53ef-4e9a-9c0b-ad11f8ced616@eisentraut.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 14.11.23 02:58, Jeff Davis wrote:
> If the user just wants PK/FK constraints, and equality lookups, then an
> index with the "C" collation makes a lot of sense to serve those
> purposes.
The problem is that the user has no way to declare whether they just
want this. The default assumption is that you get a btree and that is
useful for range queries. If the user just wants equality lookups, they
could use a hash index. Hash indexes kind of work like what we
discussed in another message: They use C collation semantics unless the
collation is declared nondeterministic. Of course, hash indexes don't
support uniqueness, but maybe that could be fixed? And/or we could
provide some other syntax that say, I want a btree but I just want
equality lookups?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2023-11-14 16:20:16 | Re: retire MemoryContextResetAndDeleteChildren backwards compatibility macro |
| Previous Message | Tom Lane | 2023-11-14 16:15:10 | Re: should check collations when creating partitioned index |