Re: Document atthasmissing default optimization avoids verification table scan

From: James Coleman <jtc331(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Document atthasmissing default optimization avoids verification table scan
Date: 2022-03-28 13:54:35
Message-ID: CAAaqYe__Gy=xCTOOJxDDeV7FQgaVmwrCNxBzw=+rDRRLAOZQUg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 28, 2022 at 9:30 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Sun, Mar 27, 2022 at 1:00 PM James Coleman <jtc331(at)gmail(dot)com> wrote:
> > So "undocumented concept" is just not accurate, and so I don't see it
> > as a valid reason to reject the patch.
>
> I mean, I think it's pretty accurate. The fact that you can point to a
> few uses of the terms "table rewrite" and "table scan" in the ALTER
> TABLE documentation doesn't prove that those terms are defined there
> or systematically discussed and it seems pretty clear to me that they
> are not. And I don't even know what we're arguing about here, because
> elsewhere in the same email you agree that it is reasonable to
> critique the patch on the basis of how well it fits into the
> documentation and at least for me that is precisely this issue.
>
> I think the bottom line here is that you're not prepared to accept as
> valid any opinion to the effect that we shouldn't commit these
> patches. But that remains my opinion.

No, I've appreciated constructive feedback from both Tom and David on
this thread. Your original email was so incredibly strongly worded
(and contained no constructive recommendations about a better path
forward, unlike Tom's and David's replies), and I had a hard time
understanding what could possibly have made you that irritated with a
proposal to document how to avoid long-running table scans while
holding an exclusive lock.

The two patches you reviewed aren't the current state of this
proposal; I'll continue working on revising to reviewers replies, and
as either a replacement or follow-on for this I like Tom's idea of
having a comprehensive guide (which I think has been needed for quite
some time).

Thanks,
James Coleman

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2022-03-28 14:17:42 Re: identifying unrecognized node type errors
Previous Message Peter Eisentraut 2022-03-28 13:45:48 Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)