Hi all,
I sometimes set autovacuum_vacuum_scale factor = 0 but only when I also
set autovacuum_vacuum_threshold to some non-zero number to force vacuums
after a certain number of rows are updated. It takes the math out of it
by setting the threshold explicitly.
But in this case he has also
=?UTF-8?Q?Lu=c3=ads_Roberto_Weck?= writes:
> As fas as autovacuum options, this is what I'm using:
> autovacuum_vacuum_scale_factor=0,
Ugh ... maybe I'm misremembering, but I *think* that has the effect
of disabling autovac completely. You don't want zero.
Check in
Em 19/09/2019 19:32, Michael Lewis escreveu:
I have about 6 bigint fields in this table that are very frequently
updated, but none of these are indexed. I thought that by not
having an
index on them, would make all updates HOT, therefore not bloating the
primary key index.
>
> I have about 6 bigint fields in this table that are very frequently
> updated, but none of these are indexed. I thought that by not having an
> index on them, would make all updates HOT, therefore not bloating the
> primary key index. Seems I was wrong?
>
HOT update is only possible if there
Em 19/09/2019 17:41, Luís Roberto Weck escreveu:
Em 19/09/2019 17:24, Luís Roberto Weck escreveu:
Em 19/09/2019 17:11, Igor Neyman escreveu:
With LIMIT 1, I get 3 shared buffers hit, pretty much always.
Em 19/09/2019 17:24, Luís Roberto Weck escreveu:
Em 19/09/2019 17:11, Igor Neyman escreveu:
With LIMIT 1, I get 3 shared buffers hit, pretty much always.
Check if assessoria_pkey index is bloated.
Em 19/09/2019 17:11, Igor Neyman escreveu:
With LIMIT 1, I get 3 shared buffers hit, pretty much always.
Check if assessoria_pkey index is bloated.
Regards,
Igor Neyman
With this query[1] it shows:
With LIMIT 1, I get 3 shared buffers hit, pretty much always.
Check if assessoria_pkey index is bloated.
Regards,
Igor Neyman
Em 19/09/2019 15:34, Igor Neyman escreveu:
-Original Message-
From: Luís Roberto Weck [mailto:luisrobe...@siscobra.com.br]
Sent: Thursday, September 19, 2019 2:30 PM
To: Michael Lewis
Cc: pgsql-performance@lists.postgresql.org
Subject: Re: Slow query on a one-tuple table
WARNING
-Original Message-
From: Luís Roberto Weck [mailto:luisrobe...@siscobra.com.br]
Sent: Thursday, September 19, 2019 2:30 PM
To: Michael Lewis
Cc: pgsql-performance@lists.postgresql.org
Subject: Re: Slow query on a one-tuple table
WARNING: This email originated from outside of Perceptron
Em 19/09/2019 14:21, Michael Lewis escreveu:
Is this result able to be repeated?
Yes, I can consistently repeat it.
Postgres version is 11.1.
Other executions:
Index Scan using assessoria_pkey on public.assessoria (cost=0.25..2.47
rows=1 width=62) (actual time=1.591..4.035 rows=1
Is this result able to be repeated?
12 matches
Mail list logo
