On Fri, 2021-01-29 at 14:13 +, Niels Jespersen wrote:
> Is there a way to get Npgsql understand the Connection Service File
> (https://www.postgresql.org/docs/13/libpq-pgservice.html). ?
>
> The purpose is to abstract physical details such as hostname, portnumber away
> from the application.
On Fri, 2021-01-29 at 15:44 +, Zwettler Markus (OIZ) wrote:
> I run "vacuumlo" in batches (-l) which worked well.
>
> I found table "pg_catalog.pg_largeobjects" to be massively bloated afterwards.
Sure, that deletes entries from that table.
> I tried "vacuum full pg_catalog.pg_largeobjects"
I run "vacuumlo" in batches (-l) which worked well.
I found table "pg_catalog.pg_largeobjects" to be massively bloated afterwards.
I tried "vacuum full pg_catalog.pg_largeobjects" but run out of diskspace
(although having 250G diskspace free; database size = 400G).
Question:
Will "vacuum full
Thomas Kellerer writes:
> Markhof, Ingolf schrieb am 29.01.2021 um 13:56:
>> So, I wonder: Is there a fundamental difference between Oracle
>> database links and foreign tables in PostgreSQL that could explain
>> the different run times?
> My guess is, that your queries use predicates that can't
Markhof, Ingolf schrieb am 29.01.2021 um 13:56:
> The set-up basically is a production database and a reporting
> database. As names indicate, the production database is used for
> production, the reporting database is for analysis. On the reporting
> database, the only way to access product data i
Hello all
Is there a way to get Npgsql understand the Connection Service File
(https://www.postgresql.org/docs/13/libpq-pgservice.html). ?
The purpose is to abstract physical details such as hostname, portnumber away
from the application.
Regards Niels Jespersen
Hi!
I am struggling with the slow performance when running queries referring to
foreign tables. - Yes, I know... - Please read the whole story!
The set-up basically is a production database and a reporting database. As
names indicate, the production database is used for production, the reportin
On Thu, 2021-01-28 at 17:03 +, Zwettler Markus (OIZ) wrote:
> We didn't recognize that an application is using large objects and didn't
> delete them.
> Now we found >100G dead large objects within the database. :-(
>
> Is there any _GENERIC_ query which enables monitoring for orphaned object
