RE: Autovacuum and visibility maps

2024-12-03 Thread Tefft, Michael J
: 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

2024-12-03 Thread Tefft, Michael J
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

2024-07-05 Thread Tefft, Michael J
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

2024-07-05 Thread Tefft, Michael J
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

2024-07-05 Thread Tefft, Michael J
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 );

2024-03-11 Thread Tefft, Michael J
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 );

2024-03-11 Thread Tefft, Michael J
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 );

2024-03-11 Thread Tefft, Michael J
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