| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Andrew <pgsqlhackers(at)andrewrepp(dot)com> |
| Subject: | Re: pg_dump versus hash partitioning |
| Date: | 2023-02-01 21:49:39 |
| Message-ID: | CAH2-Wz=s6Tkpcd6M5N9+NvxQewUq3iNBWgE8c0SVJ_4htRBSXA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Feb 1, 2023 at 12:39 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I don't think the fact that our *traditional* standard for how stable
> a hash function needs to be has been XYZ carries any water. Needs
> change over time, and we adapt the code to meet the new needs. Since
> we have no system for type properties in PostgreSQL -- a design
> decision I find questionable -- we tie all such properties to operator
> classes.
Are you familiar with B-Tree opclass support function 4, equalimage?
It's used to determine whether a B-Tree index can use deduplication at
CREATE INDEX time. ISTM that the requirements are rather similar here
-- perhaps even identical.
See: https://www.postgresql.org/docs/devel/btree-support-funcs.html
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2023-02-01 21:52:30 | Re: pg_dump versus hash partitioning |
| Previous Message | Peter Geoghegan | 2023-02-01 21:44:31 | Re: pg_dump versus hash partitioning |