| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Michail Nikolaev <michail(dot)nikolaev(at)gmail(dot)com> |
| Cc: | Greg Stark <stark(at)mit(dot)edu>, Andres Freund <andres(at)anarazel(dot)de>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Antonin Houska <ah(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCH] Full support for index LP_DEAD hint bits on standby |
| Date: | 2022-04-11 04:12:31 |
| Message-ID: | CAH2-WznMimF3z0Ab1rTfMLeveBZUUUqa-WAnY6EYP301ZpE=FA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Mar 31, 2022 at 4:57 PM Michail Nikolaev
<michail(dot)nikolaev(at)gmail(dot)com> wrote:
> I remember you had an idea about using the LP_REDIRECT bit in btree
> indexes as some kind of “recently dead” flag (1).
> Is this idea still in progress? Maybe an additional bit could provide
> a space for a better solution.
I think that the best way to make the patch closer to being
committable is to make the on-disk representation more explicit.
Relying on an implicit or contextual definition for anything seems
like something to avoid. This is probably the single biggest problem
that I see with the patch.
I suggest that you try to "work backwards". If the patch was already
committed today, but had subtle bugs, then how would we be able to
identify the bugs relatively easily? What would our strategy be then?
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Richard Guo | 2022-04-11 04:25:28 | Re: MERGE bug report |
| Previous Message | Zhihong Yu | 2022-04-11 03:58:23 | Re: generic plans and "initial" pruning |