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
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 |