On Mon, Sep 14, 2020 at 05:39:57PM -0400, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > tutiluren@xxxxxxxxxxxx writes: > > 1. All non-ANSI characters are turned into "?"s for application_name. > > Yeah, that's hard to do much with unfortunately. We cannot assume that > all databases in an installation share the same encoding, so for globally > visible strings like application_name, the only safe solution is to > restrict them to ASCII. > > On the other hand, the very same thing could be said of database names > and role names, yet we have never worried much about whether those were > encoding-safe when viewed from databases with different encodings, nor > have there been many complaints about the theoretical unsafety. So maybe > this is just overly anal-retentive and we should drop the restriction, > or at least pass through data that doesn't appear to be invalidly > encoded. Perhaps recode database/role names from the source database's encoding into utf8, and then recode from utf8 to the destination database's encoding? For "globally visible strings", maybe recode to the client_encoding setting, or a new encoding setting for this purpose since client_encoding seems to be linked to the database that the client is connected to. I'd've thought that the application name would arrive encoded as client_encoding (which defaults to the database encoding). Maybe globally visible strings need to be recoded on arrival from the client_encoding to utf8 (or a "server_encoding" or "global_encoding" setting) so they are always stored in a known encoding so they can be recoded as necessary when viewed via connections to other databases using a different encoding. Just some thoughts. If they don't make any sense, feel free to ignore them. :-) > > 5. Ever since my early days with PG in the mid-2000s, I've tried > > numerous times to read the manual, wikis and comments for the > > configuration files, specifically the performance directives, and asked > > many, many times for help about that, yet never been able to figure out > > what they want me to enter for all the numerous options. At this point, > > it isn't me being lazy/stupid; it's objectively very difficult to > > understand all of that. > > We do the best we can as far as the documentation goes; if you have > concrete suggestions about how to improve that, we'll surely listen. I thought the documentation on postgres performance tuning was fine. Here's what I got from it (for a dedicated database server host): shared_buffers = 1GB # Should be 1/4 of RAM work_mem = 16MB # Should be bigger to do more sorts in-memory but it's per sort per user so not too big maintenance_work_mem = 128MB # Should be <= 256MB to make vacuum fast without taking away too much RAM from other tasks min_wal_size = 480MB # Should be at least 3 * 10 * 16MB to avoid too many checkpoints slowing down writes checkpoint_completion_target = 0.9 # Should be 0.9 if checkpoint_segments was increased to spread out checkpoint writes random_page_cost = 4.0 # Should be 4.0 for HDD, 1.5-2.5 for SSD, 1.0-1.01 if db fits entirely in RAM effective_cache_size = 3GB # Should be 1/2 to 3/4 of RAM It's the "Should..." comments that matter. And it might be out of date... Actually, it is out of date. The comment for checkpoint_completion_target refers to checkpoint_segments which no longer exists (since 9.5) so disregard that. cheers, raf
