Re: parallel autovacuum: Propagate track_cost_delay_timing to parallel workers - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: parallel autovacuum: Propagate track_cost_delay_timing to parallel workers
Date
Msg-id CAN12+YKo428-SWRW9KiWy866jcJRPPcph+Ue6pZAvQM1VaV5jw@mail.gmail.com
Whole thread
In response to Re: parallel autovacuum: Propagate track_cost_delay_timing to parallel workers  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: parallel autovacuum: Propagate track_cost_delay_timing to parallel workers
List pgsql-hackers
Hi Bharath,

Thanks for the feedback!

> 1/ At the end of parallel_vacuum_main(), do we need to gate the
> reporting of any remaining delay time on the accumulated delay time
> variable rather than on the GUC?

track_cost_delay_timing gates delay timing reporting elsewhere, so we should not
deviate from that. If the GUC is off by then, we should not accumulate
any timing
anyhow, even if parallel_vacuum_worker_delay_ns > 0

> 2/ Turning it on in the TAP test is probably not that costly on any of
> the CI or BF animals, since our tests don't vacuum anything large, so
> it shouldn't matter.

Right. I did not think it should matter.

--
Sami Imseih
Amazon Web Services



pgsql-hackers by date:

Previous
From: Matheus Alcantara
Date:
Subject: Re: [PATCH v1] Fix for Bug#19724 - ALTER TYPE ... ALTER ATTRIBUTE triggers internal error for base type of domain with check
Next
From: Sami Imseih
Date:
Subject: Re: Parallel vacuum: I/O timings in the log leave out the parallel workers