public inbox for [email protected]  

help / color / mirror / Atom feed

Sharp edge when dropping columns
3+ messages / 3 participants
[nested] [flat]

* Sharp edge when dropping columns
@ 2024-03-14 18:44  Quentin de Metz <[email protected]>
  0 siblings, 2 replies; 3+ messages in thread

From: Quentin de Metz @ 2024-03-14 18:44 UTC (permalink / raw)
  To: [email protected]

[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

^ permalink  raw  reply  [nested|flat] 3+ messages in thread

* Re: Sharp edge when dropping columns
@ 2024-03-14 19:01  David G. Johnston <[email protected]>
  parent: Quentin de Metz <[email protected]>
  1 sibling, 0 replies; 3+ messages in thread

From: David G. Johnston @ 2024-03-14 19:01 UTC (permalink / raw)
  To: Quentin de Metz <[email protected]>; +Cc: [email protected]

On Thu, Mar 14, 2024 at 11:45 AM Quentin de Metz <[email protected]> wrote:

>
> I found this behavior unexpected.
>

In general it is advisable to rely on documented behaviors rather than
expectations.

https://www.postgresql.org/docs/current/sql-altertable.html

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.


^ permalink  raw  reply  [nested|flat] 3+ messages in thread

* Re: Sharp edge when dropping columns
@ 2024-03-14 19:17  Tom Lane <[email protected]>
  parent: Quentin de Metz <[email protected]>
  1 sibling, 0 replies; 3+ messages in thread

From: Tom Lane @ 2024-03-14 19:17 UTC (permalink / raw)
  To: Quentin de Metz <[email protected]>; +Cc: [email protected]

"Quentin de Metz" <[email protected]> writes:
> 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. 

This behavior is intentional, and we're not likely to change it.

			regards, tom lane






^ permalink  raw  reply  [nested|flat] 3+ messages in thread

end of thread, other threads:[~2024-03-14 19:17 UTC | newest]

Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-03-14 18:44 Sharp edge when dropping columns Quentin de Metz <[email protected]>
2024-03-14 19:01 ` David G. Johnston <[email protected]>
2024-03-14 19:17 ` Tom Lane <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox