Re: Add table AM 'tid_visible'

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Jinbao Chen <cjinbao(at)vmware(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add table AM 'tid_visible'
Date: 2020-12-28 08:43:26
Message-ID: CAD21AoCD7wBwcq82WapUEK5aci6RpT+EapmnDoDFRuRK8zudGg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 3, 2020 at 5:23 PM Jinbao Chen <cjinbao(at)vmware(dot)com> wrote:
>
> Hi Andres,
>
>
>
> > Yea, it's something we should improve. Have you checked if this has
>
> > performance impact for heap? Should we also consider planning costs?
>
> Since the visibility map is very small, all pages of the visibility map will
>
> usually reside in memory. The IO cost of accessing the visibility map can
>
> be ignored. We should add the CPU cost of accessing visibility map. The
>
> CPU cost of accessing visibility map is usually smaller than cpu_tuple_cost.
>
> But Postgres does not have a Macro to describe such a small cost. Should
>
> We add one?
>
>
>
> > As far as I can tell you have not acually attached the patch.
>
> Ah, forgot to upload the patch. Attach it below.

You sent in your patch, tid_visible-1.patch to pgsql-hackers on Nov 3,
but you did not post it to the next CommitFest[1]. If this was
intentional, then you need to take no action. However, if you want
your patch to be reviewed as part of the upcoming CommitFest, then you
need to add it yourself before 2021-01-01 AoE[2]. Thanks for your
contributions.

Regards,

[1] https://commitfest.postgresql.org/31/
[2] https://en.wikipedia.org/wiki/Anywhere_on_Earth

--
Masahiko Sawada
EnterpriseDB: https://www.enterprisedb.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Luc Vlaming 2020-12-28 08:44:26 Lazy JIT IR code generation to increase JIT speed with partitions
Previous Message Tang, Haiying 2020-12-28 08:15:15 RE: [Patch] Optimize dropping of relation buffers using dlist