Hi, On 2022-03-26 13:57:39 -0400, Tom Lane wrote: > Seems like making it a GUC does nothing to fix the complaint you had about > passing data to workers whether it's needed or not.
I don't think that was my complaint. Maybe Robert's? > Sure, we don't then need to write any new code for it, but it's still new > cycles. I think it'd quite possibly less cycles than separately syncing it. Because I wanted to know what the overhead be in relation to other things, I made serialize_variable() log whenever it decides to serialize, and it's a bit depressing :/. serialized DateStyle = ISO, MDY serialized default_text_search_config = pg_catalog.english serialized force_parallel_mode = on serialized lc_messages = en_US.UTF-8 serialized lc_monetary = en_US.UTF-8 serialized lc_numeric = en_US.UTF-8 serialized lc_time = en_US.UTF-8 serialized log_checkpoints = true serialized log_line_prefix = %m [%p][%b][%v:%x][%a] serialized log_timezone = America/Los_Angeles serialized max_stack_depth = 2048 serialized max_wal_size = 153600 serialized min_wal_size = 48 serialized restart_after_crash = true serialized session_authorization = andres serialized ssl_cert_file = /home/andres/tmp/pgdev/ssl-cert-snakeoil.pem serialized ssl_key_file = /home/andres/tmp/pgdev/ssl-cert-snakeoil.key serialized TimeZone = America/Los_Angeles serialized timezone_abbreviations = Default serialized track_io_timing = true serialized transaction_deferrable = false serialized transaction_isolation = read committed serialized transaction_read_only = false total serialized guc state is 1324 Of course, compared to the total size of 94784 bytes that's not too much... FWIW, 65536 of that is for the tuple queues... > I also note that exposing it as a GUC means we have zero control over > who/what can read it. Maybe that's not a problem, but it needs to be > thought about before we go down that path. Yes, I think that's a fair concern. Greetings, Andres Freund
