Thread: Sharp edge when dropping columns
[This is my first message on a PG mailing list, here's hoping I'm not breaching etiquette somehow]
Bonjour,
I'd like to report a sharp edge which caused downtime in my production application: dropping a column which is INCLUDEd in an index drops the index.
In the past, I have included a field in some of my indexes so that related queries can be performed as an index-only scan. This field was later deprecated. When the related column was ultimately dropped, the performance of the initial queries ground to a halt because the underlying index had been dropped.
I found this behavior unexpected. I think preventing the index from being dropped in some circumstances would make this less surprising. The exact circumstances likely need to be hashed out if there is a consensus that this is a (minor) problem.
Please find below a simple reproduction script:
=# CREATE TABLE test (id bigint, label text);
CREATE TABLE
=# CREATE INDEX pkey_with_label ON test USING btree (id) INCLUDE (label);
CREATE INDEX
=# \d test
Table "public.test"
┌────────┬────────┬───────────┬──────────┬─────────┐
│ Column │ Type │ Collation │ Nullable │ Default │
├────────┼────────┼───────────┼──────────┼─────────┤
│ id │ bigint │ │ │ │
│ label │ text │ │ │ │
└────────┴────────┴───────────┴──────────┴─────────┘
Indexes:
"pkey_with_label" btree (id) INCLUDE (label)
=# ALTER TABLE test DROP COLUMN label;
ALTER TABLE
=# \d test
Table "public.test"
┌────────┬────────┬───────────┬──────────┬─────────┐
│ Column │ Type │ Collation │ Nullable │ Default │
├────────┼────────┼───────────┼──────────┼─────────┤
│ id │ bigint │ │ │ │
└────────┴────────┴───────────┴──────────┴─────────┘
Thank you for reading,
Quentin de Metz
On Thu, Mar 14, 2024 at 11:45 AM Quentin de Metz <quentin@de.me.tz> wrote:
I found this behavior unexpected.
In general it is advisable to rely on documented behaviors rather than expectations.
This long-standing behavior seems unlikely to be changed. Preventing the column from being dropped would in any case be the accepted outcome, not leaving an index behind that refers to a column that doesn't exist.
David J.
"Quentin de Metz" <quentin@de.me.tz> writes:
> I'd like to report a sharp edge which caused downtime in my production application: dropping a column which is
INCLUDEdin an index drops the index.
This behavior is intentional, and we're not likely to change it.
regards, tom lane