volume is enough to justify partitioning.
Thanks in advance,
Senor
ssing something fundamental. I know what I know but I'm not a
DBA.
PG version 11 & 12 on Linux
Any hints and references appreciated.
Thanks,
Senor
rue;
blkno | all_visible | all_frozen | pd_all_visible
---+-++
(0 rows)
Thank you for any insights,
Senor
On 4/30/2024 17:31, Ron Johnson wrote:
On Tue, Apr 30, 2024 at 7:00 PM Senor Cervesa
wrote:
Hi All;
When doing an initial install of PostgreSQL on RHEL 7 or 8 derived
OS via rpm, what are pros, cons and recommendations of these 2
procedures for utilizing a second disk
starting postgres with missing data directory.
I've run postgres in both scenarios and not had any issues. I'm
interested in comments from others on their experience using these or
other options.
Thanks,
Senor
es are always appreciated.
- Senor
scripts
Your help is appreciated. If you have additional ideas, I'm all ears.
Thanks,
Senor
From: Laurenz Albe
Sent: Thursday, April 20, 2023 11:39 PM
To: senor ; pgsql-general@lists.postgresql.org
Subject: Re: vacuum TOAST tables
On Fri, 2023-04-21 at
')
AND n.nspname IN ('public','pg_toast')
AND age(c.relfrozenxid) > ${max_age}
ORDER BY 2 DESC
I've posted before about these same systems. It'll get to age(datfrozenxid) >
2,000,000,000 and is not able to keep up until I get it back down to under
~6. Then it starts humming along as if I "cleared" something.
I appreciate any advice.
Thanks
Senor
from the script and my own fat-fingering commands
> in the postgres
> logs (set at info).
Sorry about the reply formatting. I tried using outlook web in Edge. Maybe that
was a mistake.
Thanks,
Senor
um_multixact_freeze_min_age | 500
vacuum_multixact_freeze_table_age | 15000
I'm now thinking that autovacuum getting hung up is what caused the issue to
begin with. I see nothing but the successful vacuums from the script and my own
fat-fingering commands in the postgres logs (set at info).
Any hints are appreciated.
Senor
um_threshold | 50
autovacuum_work_mem | -1
work_mem | 10240
Thanks for any hints and recommendations,
Senor
#x27;m learning this from the inside out in the tradition of "well someone
has to do it". I'm sure I'm not alone.
-Senor
Thanks again
-Senor
On 4/21/2022 6:35, Laurenz Albe wrote:
On Wed, 2022-04-20 at 23:06 +, senor wrote:
I'm apparently needing an education on how this "to avoid wraparound" vacuum
differs from
any other. I've seen it referenced as "more aggressive" but I'
renced as "more aggressive" but I'd
like details. An upgrade to 13 is "right around the corner".
Pointers to documentation I might have missed is be appreciated.
-Senor
ivity indicated
pg_dump was still processing and nothing else running.
Would you say that updating to 9.2.24 would be beneficial before
upgrading to 9.6? An update is pretty quick and could be worth the time
if there aren't additional requirements prior to starting the upgrade.
Thank you.
reduction in the number of
tables should reduce the time needed but that is not the reality I'm faced with.
Thanks,
Senor
On 4/28/2019 14:08, Ron wrote:
On 4/28/19 3:21 PM, senor wrote:
Hi All,
I'm looking for advice for optimizing the pg_dump portion of "pg_upgrade
--link"
please.
Any advice and explanation is appreciated.
- Senor
e.
Thanks
From: Sherrylyn Branchaw
Sent: Sunday, April 7, 2019 6:43 AM
To: senor
Cc: pgsql-general@lists.postgresql.org
Subject: Re: pg_upgrade --jobs
are there any shortcuts to upgrading that would circumvent exporting the entire
schema?
By "shortcut
From: Adrian Klaver
Sent: Sunday, April 7, 2019 8:19 AM
To: senor; pgsql-general@lists.postgresql.org
Subject: Re: pg_upgrade --jobs
On 4/6/19 5:47 PM, senor wrote:
> Thanks Tom for the explanation. I assumed it was my ignorance of how the
> schema was handled that was making this look like a p
t DB design would be better but that's not
what I'm working with.
Thanks
From: Ron
Sent: Saturday, April 6, 2019 4:57 PM
To: pgsql-general@lists.postgresql.org
Subject: Re: pg_upgrade --jobs
On 4/6/19 6:50 PM, Tom Lane wrote:
senor <mailto
the schemas of half a million tables. As
already mentioned, if there is an alternate process that mimics pg_upgrade but
allows for paralleling, I'm open to that.
Thanks all
From: Tom Lane
Sent: Saturday, April 6, 2019 3:02 PM
To: senor
Cc: p
?
From: Adrian Klaver
Sent: Saturday, April 6, 2019 1:52 PM
To: senor; pgsql-general@lists.postgresql.org
Subject: Re: pg_upgrade --jobs
On 4/6/19 11:44 AM, senor wrote:
> The pg_upgrade --jobs option is not passed as an argument when it calls
> pg_d
The pg_upgrade --jobs option is not passed as an argument when it calls
pg_dump. I haven't found anything in docs or forums mentioning a reason for not
supporting under certain circumstances other than possibly for pre-9.2. The
pg_upgrade docs page states that it allows multiple CPUs to be used
23 matches
Mail list logo
