Re: Document atthasmissing default optimization avoids verification table scan - Mailing list pgsql-hackers

From Bossart, Nathan
Subject Re: Document atthasmissing default optimization avoids verification table scan
Date
Msg-id 70D097A9-E617-408E-8CF7-E950D8623017@amazon.com
Whole thread Raw
In response to Re: Document atthasmissing default optimization avoids verification table scan  (James Coleman <jtc331@gmail.com>)
Responses Re: Document atthasmissing default optimization avoids verification table scan
List pgsql-hackers
On 1/19/22, 5:15 PM, "James Coleman" <jtc331@gmail.com> wrote:
> I'm open to the idea of wordsmithing here, of course, but I strongly
> disagree that this is irrelevant data. There are plenty of
> optimizations Postgres could theoretically implement but doesn't, so
> measuring what should happen by what you think is obvious ("told it to
> populate with default values - why do you need to check") is clearly
> not valid.
>
> This patch actually came out of our specifically needing to verify
> that this is true before an op precisely because docs aren't actually
> clear and because we can't risk a large table scan under an exclusive
> lock. We're clearly not the only ones with that question; it came up
> in a comment on this blog post announcing the newly committed feature
> [1].

My initial reaction was similar to David's.  It seems silly to
document that we don't do something that seems obviously unnecessary.
However, I think you make a convincing argument for including it.  I
agree with David's feedback on where this information should go.

Nathan


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
Next
From: Nikita Malakhov
Date:
Subject: Re: Pluggable toaster