On 2/28/20 8:56 AM, Masahiko Sawada wrote:
According to those results, it's thought that the more we resume
vacuum from the tail of the table, the efficiency is good. Since the
table is being updated uniformly even during autovacuum it was more
efficient to restart autovacuum from last position
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: not tested
Documentation:not tested
Please fix the regression test cases.
The new status of this patch i
On Tue, 5 Nov 2019 at 15:57, Masahiko Sawada
wrote:
>
> On Sat, 2 Nov 2019 at 02:10, Robert Haas wrote:
> >
> > On Thu, Aug 8, 2019 at 9:42 AM Rafia Sabih
> > wrote:
> > > Sounds like an interesting idea, but does it really help? Because if
> > > vacuum was interrupted previously, wouldn't it a
+ VACOPT_RESUME = 1 << 8/* resume from the previous point */
I think this unused ENUM value is not needed.
Regards,
Yu Kimura
On Sat, 2 Nov 2019 at 02:10, Robert Haas wrote:
>
> On Thu, Aug 8, 2019 at 9:42 AM Rafia Sabih wrote:
> > Sounds like an interesting idea, but does it really help? Because if
> > vacuum was interrupted previously, wouldn't it already know the dead
> > tuples, etc in the next run quite quickly, as
On Thu, Aug 8, 2019 at 9:42 AM Rafia Sabih wrote:
> Sounds like an interesting idea, but does it really help? Because if
> vacuum was interrupted previously, wouldn't it already know the dead
> tuples, etc in the next run quite quickly, as the VM, FSM is already
> updated for the page in the previ
On Thu, Sep 26, 2019 at 1:53 AM Alvaro Herrera
wrote:
> Apparently this patch now has a duplicate OID. Please do use random
> OIDs >8000 as suggested by the unused_oids script.
>
> --
> Álvaro Herrerahttps://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA,
Apparently this patch now has a duplicate OID. Please do use random
OIDs >8000 as suggested by the unused_oids script.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, Aug 27, 2019 at 2:55 PM Jamison, Kirk wrote:
>
> On Monday, August 19, 2019 10:39 AM (GMT+9), Masahiko Sawada wrote:
> > Fixed.
> >
> > Attached the updated version patch.
>
> Hi Sawada-san,
>
> I haven't tested it with heavily updated large tables, but I think the patch
> is reasonable as
On Monday, August 19, 2019 10:39 AM (GMT+9), Masahiko Sawada wrote:
> Fixed.
>
> Attached the updated version patch.
Hi Sawada-san,
I haven't tested it with heavily updated large tables, but I think the patch
is reasonable as it helps to shorten the execution time of vacuum by removing
the redun
On Thu, Aug 8, 2019 at 10:42 PM Rafia Sabih wrote:
>
> On Tue, 16 Jul 2019 at 13:57, Masahiko Sawada wrote:
> >
> > On Wed, Jun 12, 2019 at 1:30 PM Masahiko Sawada
> > wrote:
> > >
> > > Hi all,
> > >
> > > Long-running vacuum could be sometimes cancelled by administrator. And
> > > autovacuums
On Tue, 16 Jul 2019 at 13:57, Masahiko Sawada wrote:
>
> On Wed, Jun 12, 2019 at 1:30 PM Masahiko Sawada wrote:
> >
> > Hi all,
> >
> > Long-running vacuum could be sometimes cancelled by administrator. And
> > autovacuums could be cancelled by concurrent processes. Even if it
> > retries after c
On Wed, Jun 12, 2019 at 1:30 PM Masahiko Sawada wrote:
>
> Hi all,
>
> Long-running vacuum could be sometimes cancelled by administrator. And
> autovacuums could be cancelled by concurrent processes. Even if it
> retries after cancellation, since it always restart from the first
> block of table i
Hi all,
Long-running vacuum could be sometimes cancelled by administrator. And
autovacuums could be cancelled by concurrent processes. Even if it
retries after cancellation, since it always restart from the first
block of table it could vacuums blocks again that we vacuumed last
time. We have visi
14 matches
Mail list logo
