Re: Records count mismatch with logical replication

On Tue, Jan 21, 2025 at 11:26 PM Adrian Klaver wrote: > On 1/21/25 09:38, Durgamahesh Manne wrote: > > > > > > > > > Hi Adrian Klaver > > > > Really Thanks for your quick response > > > > This happened during repack lag went to more than 3

Re: Records count mismatch with logical replication

On Wed, 22 Jan, 2025, 00:22 Adrian Klaver, wrote: > > > On 1/21/25 10:06 AM, Durgamahesh Manne wrote: > > > > > Hi Adrian Klaver > > > > 22,906,216 bytes/10,846 rows works out to 2112 bytes per row. > > > > Is that a reasonable per row estimate?

Records count mismatch with logical replication

Hi Team, I have publication and subscription servers .So seems data replication running with minimal lag but records count mismatch with more than 10 thousand records between source and destination tables Could you please help in resolving this issue? Regards, Durga Mahesh

Re: Query optimization

On Fri, 14 Mar, 2025, 09:11 Ron Johnson, wrote: > On Thu, Mar 13, 2025 at 11:25 PM Durgamahesh Manne < > maheshpostgr...@gmail.com> wrote: > >> On Fri, Mar 14, 2025 at 8:19 AM Ron Johnson >> wrote: >> >>> On Thu, Mar 13, 2025 at 10:16 PM Durgamahesh Ma

Re: Query optimization

On Fri, Mar 14, 2025 at 8:19 AM Ron Johnson wrote: > On Thu, Mar 13, 2025 at 10:16 PM Durgamahesh Manne < > maheshpostgr...@gmail.com> wrote: > [snip] > >> Hi Adrian Klaver >> >> 1) Postgres version. >> select version(); >>

Query optimization

Hi Team This query takes more time than usual for execution How to optimize it in best possible way Columns used in this query >> composite index eventhough not running optimally SELECT EXISTS (SELECT Key FROM CACHEKEYS WHERE CacheType = $1 AND TrsId = $2 AND BrandId = $3 AND SportId = $4 AND

Re: Query optimization

On Fri, Mar 14, 2025 at 12:47 AM Adrian Klaver wrote: > On 3/13/25 12:12, Durgamahesh Manne wrote: > > Hi Team > > > > This query takes more time than usual for execution > > Define usual. > > > > How to optimize it in best possible way > > Can

Re: Query optimization

On Fri, 14 Mar, 2025, 08:04 Rob Sargent, wrote: > > > > 3) Output of EXPLAIN ANALYZE of query. > > Result (cost=2.80..2.83 rows=1 width=1) (actual time=0.030..0.030 rows=1 > loops=1) >InitPlan 1 (returns $0) > -> Index Only Scan using idx_cachekeys on cachekeys > (cost=0.55..2.80 row

Regarding fillfactor use case for only delete ops

Hi Team Can we generate a fill factor for tables that have delete ops ? Does the fill factor really work and help to minimize the bloat for tables that have delete ops? I have parent table with weekly partitions So for every week 50 to 60 gb of bloat generates and autovacuum params already in p

Re: Regarding fillfactor use case for only delete ops

On Fri, Jun 6, 2025 at 7:29 PM Ron Johnson wrote: > On Fri, Jun 6, 2025 at 8:57 AM Laurenz Albe > wrote: > >> On Fri, 2025-06-06 at 14:10 +0530, Durgamahesh Manne wrote: >> > Can we generate a fill factor for tables that have delete ops ? >> > >> > Do

Re: Regarding fillfactor use case for only delete ops

On Fri, Jun 6, 2025 at 7:31 PM Ron Johnson wrote: > On Fri, Jun 6, 2025 at 4:36 AM Durgamahesh Manne < > maheshpostgr...@gmail.com> wrote: > >> Hi Team >> >> Can we generate a fill factor for tables that have delete ops ? >> >> Does the fill factor r

Regarding query optimisation (select for update)

Hi Team, We are facing issues with slow running query SELECT betid, versionid, betdata, processed, messagetime, createdat, updatedat FROM praermabetdata where processed = 'false' ORDER BY betid, versionid LIMIT 200 OFFSET 0 FOR UPDATE; Q

Re: Regarding query optimisation (select for update)

On Tue, Jul 15, 2025 at 6:14 PM Laurenz Albe wrote: > On Tue, 2025-07-15 at 15:40 +0530, Durgamahesh Manne wrote: > > We are facing issues with slow running query > >SELECT betid, versionid, betdata, processed, messagetime, createdat, > updatedat > >FROM praerm

<    1   2