From: | Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Dump/Restore of non-default PKs |
Date: | 2022-04-18 19:59:44 |
Message-ID: | CANbhV-GdnAc-fpUvtkwJ5+YGoKYVOmTUQp9k1A4ODo=bdJ-Oww@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At the moment you cannot create a unique index other than a btree. (As
discussed on other threads, I am pursuing unique hash indexes for
PostgreSQL, one step at a time).
You get "ERROR index foo_idx is not a btree"
According to parse_utilcmd.c line 2310, this is because it would break
pg_dump, which needs ADD CONSTRAINT to create the same kind of index
again. Fair enough.
This is needed because ADD CONSTRAINT just uses the defaults index
type. We could simply allow a GUC for
default_primary_key_access_method, but that is overkill and there
seems to be an easy and more general solution:
I propose that we change pg_dump so that when it creates a PK it does
so in 2 commands:
1. CREATE [UNIQUE] INDEX iname ...
2. ALTER TABLE .. ADD PRIMARY KEY USING INDEX iname;
Step
(1) recreates the index, respecting its AM, even if that is not a btree
(2) works and there is no problem with defaults
Doing this as 2 steps instead of one doesn't add any more time because
(2) is just a metadata-only change, not an index build.
Any objections to a patch to implement this thought?
--
Simon Riggs http://www.EnterpriseDB.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2022-04-18 20:04:32 | Re: Preventing indirection for IndexPageGetOpaque for known-size page special areas |
Previous Message | Peter Geoghegan | 2022-04-18 19:54:36 | Re: Why does pg_class.reltuples count only live tuples in indexes (after VACUUM runs)? |