Re: [DOCS] HOT - correct claim about indexes not referencing old line pointers

Поиск
Список
Период
Сортировка
От James Coleman
Тема Re: [DOCS] HOT - correct claim about indexes not referencing old line pointers
Дата
Msg-id CAAaqYe9ro_Ch0mHdr4Bp2R33KRp=ZE4jXvmmK-0NXX5z8yXf1w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [DOCS] HOT - correct claim about indexes not referencing old line pointers  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [DOCS] HOT - correct claim about indexes not referencing old line pointers  (Robert Haas <robertmhaas@gmail.com>)
Re: [DOCS] HOT - correct claim about indexes not referencing old line pointers  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Thu, Mar 14, 2024 at 10:28 AM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Wed, Oct 4, 2023 at 9:12 PM James Coleman <jtc331@gmail.com> wrote:
> > All right, attached is a v3 which attempts to fix the wrong
> > information with an economy of words. I may at some point submit a
> > separate patch that adds a broader pruning section, but this at least
> > brings the docs inline with reality insofar as they address it.
>
> I don't think this is as good as what I proposed back on October 2nd.
> IMHO, that version does a good job making the text accurate and clear,
> and is directly responsive to your original complaint, namely, that
> the root of the HOT chain can't be removed. But this version seems to
> contain a number of incidental changes that are unrelated to that
> point, e.g. "old versions" -> "old, no longer visible versions", "can
> be completely removed" -> "may be pruned", and the removal of the
> sentence "In summary, heap-only tuple updates can only be created - if
> columns used by indexes are not updated" which AFAICT is both
> completely correct as-is and unrelated to the original complaint.
>
> Maybe I shouldn't be, but I'm slightly frustrated here. I thought I
> had proposed an alternative which you found acceptable, but then you
> proposed several more versions that did other things instead, and I
> never really understood why we couldn't just adopt the version that
> you seemed to think was OK. If there's a problem with that, say what
> it is. If there's not, let's do that and move on.

I think there's simply a misunderstanding here. I read your proposal
as "here's an idea to consider as you work on the patch" (as happens
on many other threads), and so I attempted to incorporate your primary
points of feedback into my next version of the patch.

Obviously I have reasons for the other changes I made: for example,
"no longer visible" improves the correctness, since being an old
version isn't sufficient. I removed the "In summary" sentence because
it simply doesn't follow from the prose before it. That sentence
simply restates information already appearing earlier in almost as
simple a form, so it's redundant. But more importantly it's just not
actually a summary of the text before it, so removing it improves the
documentation.

I can explain my reasoning further if desired, but I fear it would
simply frustrate you further, so I'll stop here.

If the goal here is the most minimal patch possible, then please
commit what you proposed. I am interested in improving the document
further, but I don't know how to do that easily if the requirement is
effectively "must only change one specific detail at a time". So, that
leaves me feeling a bit frustrated also.

Regards,
James Coleman



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Support json_errdetail in FRONTEND builds
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: cleanup patches for incremental backup