On 12/2/24 17:17, Tom Lane wrote:
PopeRigby writes:
On 12/1/24 12:15, Tom Lane wrote:
Cool. You did actually install the new scripts into your target
installation, right?
Oh, is applying the patch and rebuilding PostgreSQL not enough?
Not unless you did "make install" in the contrib/earthdi
On 12/3/24 09:43, Sasmit Utkarsh wrote:
Dear PostgreSQL Community Team,
I am working on a project that uses libpq along with C language to
interact with PostgreSQL, and we face challenges with managing schema
changes dynamically in production while avoiding downtime. Specifically,
we need gui
On 12/3/24 10:11 AM, Tefft, Michael J wrote:
Thanks for the point about truncates versus deletes.
But most of these partitions have over 100k rows, all inserted at once.
We have the default setting:
#autovacuum_vacuum_insert_threshold = 1000 # min number of row inserts
So I thought w
Database randomdata did not fully restore.
This consistently does not work.
Am I missing a step or concept about how PITR works?
I am using postgres version: PostgreSQL 17.2 on x86_64-windows
Steps:
1) Updated postgresql.conf:
archive_mode = on
archive_command = 'copy "%p" "C:\\PostgresArc
On Tue, Dec 3, 2024 at 12:44 PM Sasmit Utkarsh
wrote:
[snip]
> How can we efficiently handle table additions/updates while keeping the
> application and database in sync dynamically?
>
Enumerate all relevant column names in SELECT and INSERT statements. That
way, the application still works whe
We have a docker setup for pgadmin and we want to force autocomplete on
keypress at launch (not through the preferences) using an environment variable
or config of some sort. I tried modifying the file at
https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/tools/sqleditor/utils/query
When in doubt, "manually" vacuum and/or analyze.
Maybe even disable autovacuum on that table before the TRUNCATE + INSERT,
do the "manual" vacuum-analyze and then re-enable autovacuum. Bonus points
for programmatically determining which partitions you're going to insert
into, so that you only man
Thanks for the point about truncates versus deletes.
But most of these partitions have over 100k rows, all inserted at once. We have
the default setting:
#autovacuum_vacuum_insert_threshold = 1000 # min number of row inserts
So I thought we should be triggering by inserts.
Mike
From: Adria
On Tue, Dec 3, 2024 at 11:57 AM Adrian Klaver
wrote:
[snip]
>
> I have to believe it is due to this:
>
>
> https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-SPACE-RECOVERY
>
> "If you have a table whose entire contents are deleted on a periodic
> basis, consider doing it w
Dear PostgreSQL Community Team,
I am working on a project that uses libpq along with C language to interact
with PostgreSQL, and we face challenges with managing schema changes
dynamically in production while avoiding downtime. Specifically, we need
guidance on handling table structure changes/add
On 12/3/24 08:32, Tefft, Michael J wrote:
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 sc
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
12 matches
Mail list logo
