o
> "NOT in replication list" tables ? that can help reduce this kind of
> error.
>
> Thanks,
>
> James
>
>
>>
>>
>>
>> *From:* khan Affan
>> *Sent:* Wednesday, July 31, 2024 1:42 PM
>> *To:* James Pang
>> *Cc:* pgsql-
From:* khan Affan
> *Sent:* Wednesday, July 31, 2024 1:42 PM
> *To:* James Pang
> *Cc:* pgsql-performance@lists.postgresql.org
> *Subject:* Re: logical replication out of memory
>
>
>
> Hi Pang
>
> The text column is exceptionally large, Your server must be out of memory,
Hi Pang
The text column is exceptionally large, Your server must be out of memory,
Such a process ran out of memory while handling a large text column update.
I suggest using an S3 bucket for such files, Consider increasing the
memory-related configuration parameters, like work_mem, maintenance_
We use built-in pgoutput and a client application did an HOT update to
a column , that data type is "text" and real length is 756711422. But this
table is NOT on publication list, possible to make logical decoding ignore
"WAL records belong to tables that's not in publication list" ? or we
h
On Thu, Aug 5, 2021 at 12:57 AM Nikhil Shetty
wrote:
> Hi,
>
> Thank you for the suggestion.
>
> We tried by dropping indexes and it worked faster compared to what we saw
> earlier. We wanted to know if anybody has done any other changes that helps
> speed-up initial data load without dropping in
On Fri, 6 Aug 2021 at 00:15, Nikhil Shetty wrote:
> Hi Vijaykumar,
>
> Thanks for the details.
> In this method you are saying the pg_basebackup will make the initial load
> faster ?
>
We intend to bring only a few tables. Using pg_basebackup will clone an
> entire instance.
>
yeah. In that case
Hi Vijaykumar,
Thanks for the details.
In this method you are saying the pg_basebackup will make the initial load
faster ?
We intend to bring only a few tables. Using pg_basebackup will clone an
entire instance.
Thanks,
Nikhil
On Thu, Aug 5, 2021 at 7:57 PM Vijaykumar Jain <
vijaykumarjain.git
Hi Avinash,
Thank you for the detailed explanation.
Indexes were dropped on the destination to increase initial data load
speed. We cannot stop the App on source and it is highly transactional.
I had thought about this method but I am not sure after the pg_restore from
where the logical replicati
Hi,
On Thu, Aug 5, 2021 at 11:28 AM Vijaykumar Jain <
vijaykumarjain.git...@gmail.com> wrote:
> On Thu, 5 Aug 2021 at 10:27, Nikhil Shetty wrote:
>
>> Hi,
>>
>> Thank you for the suggestion.
>>
>> We tried by dropping indexes and it worked faster compared to what we saw
>> earlier. We wanted to
On Thu, 5 Aug 2021 at 10:27, Nikhil Shetty wrote:
> Hi,
>
> Thank you for the suggestion.
>
> We tried by dropping indexes and it worked faster compared to what we saw
> earlier. We wanted to know if anybody has done any other changes that helps
> speed-up initial data load without dropping index
On Thu, Aug 5, 2021 at 12:57 AM Nikhil Shetty
wrote:
> Hi,
>
> Thank you for the suggestion.
>
> We tried by dropping indexes and it worked faster compared to what we saw
> earlier. We wanted to know if anybody has done any other changes that helps
> speed-up initial data load without dropping in
Hi Stefano,
Thank you for the information.
Regards,
Nikhil
On Wed, Aug 4, 2021 at 9:25 PM Stefano Amoroso
wrote:
> Hello,
> in my experience, to speed up the initial load, I had to drop UKs and FKs.
> Unfortunately, the initial load doesn't work in parallel and, for each
> table, there is only
Hi,
Thank you for the suggestion.
We tried by dropping indexes and it worked faster compared to what we saw
earlier. We wanted to know if anybody has done any other changes that helps
speed-up initial data load without dropping indexes.
Thanks,
Nikhil
On Wed, Aug 4, 2021 at 8:54 PM Hüseyin Demi
> On Aug 4, 2021, at 08:06, Nikhil Shetty wrote:
>
> How can we increase the speed of the initial data load without dropping the
> indexes on destination?
You can do the usual steps of increasing checkpoint_timeout and max_wal_size
(since incoming logical replication changes are WAL logged)
Hello,
in my experience, to speed up the initial load, I had to drop UKs and FKs.
Unfortunately, the initial load doesn't work in parallel and, for each
table, there is only one sync worker.
Regards
Stefano Amoroso
Il giorno mer 4 ago 2021 alle ore 17:24 Hüseyin Demir <
demirhuseyinn...@gmail.co
Hello,
I also faced a similar issue. Try removing the indexes on the destination
first if possible. After that, you can add the indexes.
Regards.
Nikhil Shetty , 4 Ağu 2021 Çar, 18:07 tarihinde
şunu yazdı:
> Hi Team,
>
> We have a highly transactional system as the source of logical replicatio
perfect :-)
thanks
Marc MILLAS
Senior Architect
+33607850334
www.mokadb.com
On Fri, May 21, 2021 at 3:21 PM Andrew Dunstan wrote:
>
> On 5/21/21 8:41 AM, Marc Millas wrote:
> > Hi,
> >
> > my POC in postgres 12.(important ?)
> >
> > if I setup 2 postgres clusters, and create a publication in
On 5/21/21 8:41 AM, Marc Millas wrote:
> Hi,
>
> my POC in postgres 12.(important ?)
>
> if I setup 2 postgres clusters, and create a publication in one and a
> subscription in the other,
> and do on the pub an update which does not change the data (updating
> an existing record with same data) t
On Fri, Nov 29, 2019 at 11:06 AM Florian Philippon <
florian.philip...@doctolib.com> wrote:
>
> We tried another solution: we loaded a minimal schema (without indexes and
> constraints) on the subscriber and created the subscription. The initial
> copy phase was way faster (a few hours). Then we c
Em sex., 29 de nov. de 2019 às 17:06, Florian Philippon <
florian.philip...@doctolib.com> escreveu:
> Hello community!
>
> Hi Florian
> We are currently testing PostgreSQL 11's built-in logical replication. We
> are trying to initialize a subscriber (from scratch) from a publisher with
> a large
20 matches
Mail list logo
