Alvaro,
Thanks for the insight, was really helpful!
Best,
Martín
On Fri, Sep 14th, 2018 at 12:41 PM, Alvaro Herrera
wrote:
>
>
>
> On 2018-Sep-13, Martín Fernández wrote:
>
> > By performing this changes we are going to start relying more heavily
> > on the autovacuum work and the
On 2018-Sep-13, Martín Fernández wrote:
> By performing this changes we are going to start relying more heavily
> on the autovacuum work and the concern of "lost work" caused by
> autovacuum canceling itself when locking contention happen showed up.
> I'm guessing that we might be over thinking
Tom,
Thanks for the detailed explanation. I can start mapping your explanation with
the source code I've been reading :)
We are in the process of tuning our autovacuum settings (on some tables) and
stop relying on crontabs that are performing manual vacuums.
By performing this changes we are
=?UTF-8?q?Mart=C3=ADn_Fern=C3=A1ndez?= writes:
> We basically started a VACUUM on a given table, waited for one index to
> process (captured cleaned rows count) and cancel the VACUUM. When we run
> another VACUUM on the same table the dead rows removed from the first index
> was a number
David,
Your last comment applies for cleaning up indexes as well ? We performed a
simple test in our production database to understand behaviour and we got a
result that surprised us based on your last comment.
We basically started a VACUUM on a given table, waited for one index to process
David,
Thanks a lot for the quick reply.
I clearly misunderstood the references in the code.
Best,
Martín
On Thu, Sep 13th, 2018 at 7:55 PM, "David G. Johnston"
wrote:
>
>
> On Thu, Sep 13, 2018 at 3:45 PM, Martín Fernández < fmarti...@gmail.com >
> wrote:
>
>
>> From what I could
On Thu, Sep 13, 2018 at 3:45 PM, Martín Fernández
wrote:
> From what I could understand (that can be totally wrong), the vacuum
> process is split in multiple small transactions. If the autovacuum is
> canceled, could it be possible that only the latest transaction work be
> lost
>
>From the
