Re: improve DEBUG1 logging of parallel workers for CREATE INDEX?

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":

> https://www.postgresql.org/message-id/CAM-w4HNm1M5J-ow8UjTcqRe3JPxkVCrGe56tRpPUSePSdGcZ_w%40mail.gmail.com

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

In response to

Browse pgsql-hackers by date

  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