Re: Logical Replication speed-up initial data

< 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 know if anybody has done

Re: Logical Replication speed-up initial data

gt; 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

Re: Logical Replication speed-up initial data

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 th

Re: Logical Replication speed-up initial data

Demir wrote: > 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, >>

Logical Replication speed-up initial data

Hi Team, We have a highly transactional system as the source of logical replication and the database size is 500GB+. We are replicating all tables from source using logical replication. For two tables the initial data load is very slow and it never completes even after 24hrs+ Table size is under

Re: How do we hint a query to use index in postgre

How about using pg_hint_plans? Check it out if it helps your case. Thanks and Regards, Nikhil On Thu, Mar 18, 2021, 15:07 Manish Lad wrote: > Thank you for your response. > > > > > On Thu, 18 Mar 2021, 14:46 Gaetano Mendola, wrote: > >> There is not such functionality, you can enable/disable

Re: Recommended value for pg_test_fsync

be compared to benchmark throughput but both are indicative of overall database performance. WAL sync should not become a bottleneck during actual production workload. Thanks and Regards, Nikhil On Wed, Jul 1, 2020 at 11:13 PM Nikhil Shetty wrote: > Hi Haroldo, > > Thank you for th

Re: Recommended value for pg_test_fsync

uler is CFQ, changing to deadline provided us the 10x > difference that we were expecting. > In the end this was buried on the storage documentation that > somehow slipped us... > Hope this helps. > Regards, > Haroldo Kerry > > On Wed, Jul 1, 2020 at 2:06 PM Nikhil Shetty &g

Re: Recommended value for pg_test_fsync

Hi Jeff, To avoid confusion, Hitachi Storage G900 has 41Gbps Performance bandwidth (Throughput) and 10Gbps N/W bandwidth. Thanks and Regards, Nikhil On Wed, Jul 1, 2020 at 10:36 PM Nikhil Shetty wrote: > Hi Jeff, > > Thank you for your inputs. We may stick with fdatasync for now

Re: Recommended value for pg_test_fsync

PM Jeff Janes wrote: > On Mon, Jun 29, 2020 at 5:27 AM Nikhil Shetty > wrote: > >> Hi Team, >> >> We have a PostgreSQL 11.5.6 database running on VM. >> RAM - 48GB >> CPU - 6 cores >> Disk - SSD on SAN >> >> We wanted to check how the WA

Re: Recommended value for pg_test_fsync

Hi Bruce, Thank you. We may stick with fdatasync for now. Thanks and regards, Nikhil On Tue, Jun 30, 2020 at 8:54 PM Bruce Momjian wrote: > On Tue, Jun 30, 2020 at 10:32:13AM +0530, Nikhil Shetty wrote: > > Hi Bruce, > > > > Based on pg_test_fsync results, should we ch

Re: Recommended value for pg_test_fsync

Jun 29, 2020 at 02:56:42PM +0530, Nikhil Shetty wrote: > > Hi Team, > > > > We have a PostgreSQL 11.5.6 database running on VM. > > RAM - 48GB > > CPU - 6 cores > > Disk - SSD on SAN > > > > We wanted to check how the WAL disk is performing using pg_te

Recommended value for pg_test_fsync

Hi Team, We have a PostgreSQL 11.5.6 database running on VM. RAM - 48GB CPU - 6 cores Disk - SSD on SAN We wanted to check how the WAL disk is performing using pg_test_fsync.We ran a test and got around 870 ops/sec for opendatasync and fdatasync and just 430 ops/sec for fsync.We feel it is quite