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  (Andrew Dunstan <andrew@dunslane.net>)
Список 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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
Следующее
От: Nikita Malakhov
Дата:
Сообщение: Re: Pluggable toaster