Re: Document atthasmissing default optimization avoids verification table scan
От | Bossart, Nathan |
---|---|
Тема | Re: Document atthasmissing default optimization avoids verification table scan |
Дата | |
Msg-id | 70D097A9-E617-408E-8CF7-E950D8623017@amazon.com обсуждение исходный текст |
Ответ на | Re: Document atthasmissing default optimization avoids verification table scan (James Coleman <jtc331@gmail.com>) |
Ответы |
Re: Document atthasmissing default optimization avoids verification table scan
|
Список | 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 по дате отправления: