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
