Re: Document atthasmissing default optimization avoids verification table scan

From: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
To: James Coleman <jtc331(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Document atthasmissing default optimization avoids verification table scan
Date: 2022-01-20 17:25:40
Message-ID: 70D097A9-E617-408E-8CF7-E950D8623017@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1/19/22, 5:15 PM, "James Coleman" <jtc331(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nikita Malakhov 2022-01-20 18:24:56 Re: Pluggable toaster
Previous Message Peter Geoghegan 2022-01-20 16:45:07 Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations