Re: New IndexAM API controlling index vacuum strategies

Zhihong Yu <zyu@yugabyte.com>

From: Zhihong Yu <zyu@yugabyte.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Peter Geoghegan <pg@bowt.ie>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-01-25T16:05:26Z
Lists: pgsql-hackers
Hi,
bq. We can mention in the commit log that since the commit changes
MaxHeapTuplesPerPage the encoding in gin posting list is also changed.

Yes - this is fine.

Thanks

On Mon, Jan 25, 2021 at 12:28 AM Masahiko Sawada <sawada.mshk@gmail.com>
wrote:

> (Please avoid top-posting on the mailing lists[1]: top-posting breaks
> the logic of a thread.)
>
> On Tue, Jan 19, 2021 at 12:02 AM Zhihong Yu <zyu@yugabyte.com> wrote:
> >
> > Hi, Masahiko-san:
>
> Thank you for reviewing the patch!
>
> >
> > For v2-0001-Introduce-IndexAM-API-for-choosing-index-vacuum-s.patch :
> >
> > For blvacuumstrategy():
> >
> > +   if (params->index_cleanup == VACOPT_TERNARY_DISABLED)
> > +       return INDEX_VACUUM_STRATEGY_NONE;
> > +   else
> > +       return INDEX_VACUUM_STRATEGY_BULKDELETE;
> >
> > The 'else' can be omitted.
>
> Yes, but I'd prefer to leave it as it is because it's more readable
> without any performance side effect that we return BULKDELETE if index
> cleanup is enabled.
>
> >
> > Similar comment for ginvacuumstrategy().
> >
> > For v2-0002-Choose-index-vacuum-strategy-based-on-amvacuumstr.patch :
> >
> > If index_cleanup option is specified neither VACUUM command nor
> > storage option
> >
> > I think this is what you meant (by not using passive voice):
> >
> > If index_cleanup option specifies neither VACUUM command nor
> > storage option,
> >
> > - * integer, but you can't fit that many items on a page. 11 ought to be
> more
> > + * integer, but you can't fit that many items on a page. 13 ought to be
> more
> >
> > It would be nice to add a note why the number of bits is increased.
>
> I think that it might be better to mention such update history in the
> commit log rather than in the source code. Because most readers are
> likely to be interested in why 12 bits for offset number is enough,
> rather than why this value has been increased. In the source code
> comment, we describe why 12 bits for offset number is enough. We can
> mention in the commit log that since the commit changes
> MaxHeapTuplesPerPage the encoding in gin posting list is also changed.
> What do you think?
>
> > For choose_vacuum_strategy():
> >
> > +       IndexVacuumStrategy ivstrat;
> >
> > The variable is only used inside the loop. You can use
> vacrelstats->ivstrategies[i] directly and omit the variable.
>
> Fixed.
>
> >
> > +       int ndeaditems_limit = (int) ((freespace / sizeof(ItemIdData)) *
> 0.7);
> >
> > How was the factor of 0.7 determined ? Comment below only mentioned
> 'safety factor' but not how it was chosen.
> > I also wonder if this factor should be exposed as GUC.
>
> Fixed.
>
> >
> > +   if (nworkers > 0)
> > +       nworkers--;
> >
> > Should log / assert be added when nworkers is <= 0 ?
>
> Hmm I don't think so. As far as I read the code, there is no
> possibility that nworkers can be lower than 0 (we always increment it)
> and actually, the code works fine even if nworkers is a negative
> value.
>
> >
> > + * XXX: allowing to fill the heap page with only line pointer seems a
> overkill.
> >
> > 'a overkill' -> 'an overkill'
> >
>
> Fixed.
>
> The above comments are incorporated into the latest patch I just posted[2].
>
> [1] https://en.wikipedia.org/wiki/Posting_style#Top-posting
> [2]
> https://www.postgresql.org/message-id/CAD21AoCS94vK1fs-_%3DR5J3tp2DsZPq9zdcUu2pk6fbr7BS7quA%40mail.gmail.com
>
>
>
>
> --
> Masahiko Sawada
> EDB:  https://www.enterprisedb.com/
>

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Don't truncate heap when VACUUM's failsafe is in effect.

  2. Teach VACUUM to bypass unnecessary index vacuuming.

  3. Add wraparound failsafe to VACUUM.

  4. Truncate line pointer array during VACUUM.

  5. Remove tupgone special case from vacuumlazy.c.

  6. Refactor lazy_scan_heap() loop.

  7. Propagate parallel VACUUM's buffer access strategy.

  8. Simplify state managed by VACUUM.

  9. Notice that heap page has dead items during VACUUM.

  10. Adjust lazy_scan_heap() accounting comments.

  11. Use full 64-bit XID for checking if a deleted GiST page is old enough.

  12. Fix some problems with VACUUM (INDEX_CLEANUP FALSE).