From: | Shayon Mukherjee <shayonj(at)gmail(dot)com> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Michael Banck <mbanck(at)gmx(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Proposal to Enable/Disable Index using ALTER INDEX |
Date: | 2024-09-10 12:15:19 |
Message-ID: | CANqtF-qUrzsfNvjr-YYQA2DJk1KMGUqg+MjYfKLW1nkZr2ApuQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
+1 for the new flag as well, since it'd be nice to be able to
enable/disable indexes without having to worry about the missed updates /
having to rebuild it.
Shayon
On Tue, Sep 10, 2024 at 8:02 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> On Tue, 10 Sept 2024 at 22:46, Michael Banck <mbanck(at)gmx(dot)net> wrote:
> > How about the indislive flag instead? I haven't looked at the code, but
> > from the documentation ("If false, the index is in process of being
> > dropped, and
> > should be ignored for all purposes") it sounds like we made be able to
> > piggy-back on that instead?
>
> Doing that could cause an UPDATE which would ordinarily not be
> eligible for a HOT-update to become a HOT-update. That would cause
> issues if the index is enabled again as the index wouldn't have been
> updated during the UPDATE.
>
> I don't see the big deal with adding a new flag. There's even a free
> padding byte to put this flag in after indisreplident, so we don't
> have to worry about using more memory.
>
> David
>
--
Kind Regards,
Shayon Mukherjee
From | Date | Subject | |
---|---|---|---|
Next Message | Rafia Sabih | 2024-09-10 12:22:11 | Re: Retiring is_pushed_down |
Previous Message | torikoshia | 2024-09-10 12:03:40 | Re: ANALYZE ONLY |