From: | Sami Imseih <samimseih(at)gmail(dot)com> |
---|---|
To: | Guillaume Lelarge <guillaume(at)lelarge(dot)info> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: improve DEBUG1 logging of parallel workers for CREATE INDEX? |
Date: | 2025-01-22 00:33:00 |
Message-ID: | CAA5RZ0tTC66X2TZURqR9ThFt7YPVwGwFUBVYkvjn3=zuRKq4UA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> You might be interested by this thread "Thinking about EXPLAIN ALTER TABLE":
I reviewed this thread, and the primary issue with the EXPLAIN command lies
in the inability to predict all the steps the ALTER TABLE will take as some
are made in phase 2 or 3. It is unlikely that all significant
decisions can be made
in phase 1.
However, I don't think that EXPLAIN addresses the same problem as the proposed
VERBOSE option. Consider, for instance, a user who intends to perform a schema
change that includes a long sequence of ALTERs. These steps will depend on each
other. Tom raises this point of dependent ALTERs [2] but for a
different reason.
I think however, this is an important point. How will EXPLAIN help
here? It may not tell
you the truth, because it does not actually do the work and can't know
the future
state of the schema.
VERBOSE on the other hand will perform the steps, and a user
can test these changes in a test environment or a schema-only restore
and know exactly what to expect in production.
As this thread has expanded beyond its original scope,
I believe this broader discussion is valuable. Rather than merely
addressing the DEBUG1 issue, we can work toward a more complete
and beneficial solution.
Thoughts?
[0] https://www.postgresql.org/message-id/26597.1544460770%40sss.pgh.pa.us
Regards,
Sami
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2025-01-22 00:46:53 | Re: [PATCH] Optionally record Plan IDs to track plan changes for a query |
Previous Message | Michael Paquier | 2025-01-22 00:14:22 | Re: Show WAL write and fsync stats in pg_stat_io |