Capturing both IP address and hostname in the log

The documentation for log_hostname says: log_hostname (boolean) By default, connection log messages only show the IP address of the connecting host. Turning this parameter on causes logging of the host name as well. Note that depending on your host name resolution setup this might impose a non-n

RE: Autovacuum and visibility maps

: Adrian Klaver Sent: Tuesday, December 3, 2024 11:57 AM To: Tefft, Michael J ; pgsql-general@lists.postgresql.org Subject: Re: Autovacuum and visibility maps On 12/3/24 08: 32, Tefft, Michael J wrote: > We have some batch queries that had occasionally having degraded > runtimes: from 2

Autovacuum and visibility maps

We have some batch queries that had occasionally having degraded runtimes: from 2 hours degrading to 16 hours, etc. Comparing plans from good and bad runs, we saw that the good plans used index-only scans on table "x", while the bad plans used index scans. Using the pg_visibility utility, we fo

RE: Removing the default grant of EXECUTE on functions/procedures to PUBLIC

2 PM To: Tefft, Michael J Cc: pgsql-general@lists.postgresql.org Subject: Re: Removing the default grant of EXECUTE on functions/procedures to PUBLIC "Tefft, Michael J" writes: > I was checking pg_roles. acl_default to see if my role-level ALTER DEFAULT PRIVILEGES had been effect

RE: Removing the default grant of EXECUTE on functions/procedures to PUBLIC

be checking instead? Thanks, Mike Tefft From: Tom Lane Sent: Friday, July 5, 2024 10:51 AM To: Tefft, Michael J Cc: pgsql-general@lists.postgresql.org Subject: Re: Removing the default grant of EXECUTE on functions/procedures to PUBLIC "Tefft, Michael J" writes: > I am trying t

Removing the default grant of EXECUTE on functions/procedures to PUBLIC

I am trying to remove the default grant of EXECUTE on all functions/procedures to PUBLIC. >From my reading, there is no straightforward way to do this. For example, ALTER DEFAULT PRIVILEGES REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC; Does not apply this across the entire cluster (or database) but onl

RE: alter table xxx alter column yyy set (n_distinct=nnnn );

where schemaname='sss' and tablename='xxx' and attname = ‘col1’; So setting n_distinct on the column at the parent/partitioned-table level is not relevant for this. Thanks again. Mike Tefft From: Greg Sabino Mullane Sent: Monday, March 11, 2024 12:23 PM To: Laurenz Albe

RE: alter table xxx alter column yyy set (n_distinct=nnnn );

negative, but none carry the value I attempted to set Thanks, Mike Tefft -Original Message- From: Laurenz Albe Sent: Monday, March 11, 2024 9:21 AM To: Tefft, Michael J ; pgsql-general@lists.postgresql.org Subject: Re: alter table xxx alter column yyy set (n_distinct= ); On Mon

alter table xxx alter column yyy set (n_distinct=nnnn );

I have been struggling to set n_distinct on a few table columns, and confirm that my changes have actually been accepted. I have a 400-million row table with 81 partitions. PostgreSQL version is 14.11. Column p_id has 13 million distinct values but pg_stats says n_distinct is only 82k. Column pi