Le sam. 7 mai 2022 à 15:27, Hasan Marzooq a écrit :
> Hello!
>
> Thanks Guillaume and Ron!
>
> I understand REINDEXING is not required, and as Guillaume highlighted,
> vacuum will still be needed after pg_restore.
>
> Is it ok to perform a "standard" vacuum or do we need a "FULL"
> vacuum after p
On Saturday, May 7, 2022, Durumdara wrote:
>
>
> So is there any syntax to not fall on missing columns?
>
No. I’d probably approach this by generically converting the NEW record to
json and working with that. Non-existent object keys return null when
accessed.
David J.
Hello!
Thanks Guillaume and Ron!
I understand REINDEXING is not required, and as Guillaume highlighted,
vacuum will still be needed after pg_restore.
Is it ok to perform a "standard" vacuum or do we need a "FULL" vacuum after
pg_restore?
Also, I think finding tables which have dead rows and the
Hello!
We stored the username in a temporary table which was created by the client
app.
With this technique we can log these names in triggers too.
Now we extend it with user id and later the comp name.
Because we can update the client applications slowly, some client's tables
have these one or
Le sam. 7 mai 2022 à 10:21, Ron a écrit :
> On 5/6/22 21:35, Hasan Marzooq wrote:
>
> Hello!
>
> I've some questions around Backup & Restore.
>
> 1: Is it necessary to perform a VACUUM and REINDEXING operation after
> restoring the dump from Postgres 9.6 to Postgres 13? The dump size could be
> 1
On 5/6/22 21:35, Hasan Marzooq wrote:
Hello!
I've some questions around Backup & Restore.
1: Is it necessary to perform a VACUUM and REINDEXING operation after
restoring the dump from Postgres 9.6 to Postgres 13? The dump size could
be 1/2 TB to 1 TB.
Perform VACUUM after there have been ma
Hi,
Le sam. 7 mai 2022 à 04:36, Hasan Marzooq a écrit :
> Hello!
>
> I've some questions around Backup & Restore.
>
> 1: Is it necessary to perform a VACUUM and REINDEXING operation after
> restoring the dump from Postgres 9.6 to Postgres 13? The dump size could be
> 1/2 TB to 1 TB.
>
>
You can
