debug_print_raw_parse

Definition PG 20 devel manual

These parameters enable various debugging output to be emitted. When set, they print the resulting raw parse tree, the parse tree, the query rewriter output, or the execution plan for each executed query. These messages are emitted at LOG message level, so by default they will appear in the server log but will not be sent to the client. You can change that by adjusting client_min_messages and/or log_min_messages. These parameters are off by default.

How it works

PostgreSQL describes debug_print_raw_parse as follows: “Logs each query's raw parse tree.” It can be changed per session, which makes plan or behavior comparisons possible without changing every workload. The atlas measures it in PG19 Beta 3; boot_val is the compiled or initialized baseline, not proof of a running cluster's effective setting.

The raw parse tree is emitted before parse analysis, rewriting, planning, and execution. Messages use LOG level; debug_pretty_print changes formatting, while client_min_messages and log_min_messages determine where they are visible. Output can be very large and can expose query text structure.

Read it together with debug_print_parse, debug_print_rewritten, debug_print_plan, debug_pretty_print. Check SHOW and pg_settings on the target server, verify the source and pending_restart fields, and compare workload, logs, and resource metrics before and after any change.

Operational considerations

Treating the measured boot_val for debug_print_raw_parse as proof of the effective value on an initialized or managed cluster.

Applying a change as though it were immediate while pg_settings reports user context.

Changing this setting in isolation without checking the linked limits, observability, and rollback path.

Depending on beta behavior in production without retesting the PostgreSQL 19 final release.

Workload guidance

OLAP: Evaluate the setting with representative long-running and batch work. Measure total runtime, resource use, log volume, and failure behavior across the whole job rather than one isolated operation.

OLTP: Keep the upstream default until a reproducible operational need is demonstrated. Test under representative concurrency and inspect logs, latency, and the related settings before changing cluster-wide policy.

SMALL: Minimize overrides and document rollback. A small system has less room for extra logging, workers, memory, or retained WAL, so validate the change with explicit resource limits.