From: | James Coleman <jtc331(at)gmail(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | "Bossart, Nathan" <bossartn(at)amazon(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Document atthasmissing default optimization avoids verification table scan |
Date: | 2022-01-20 20:43:37 |
Message-ID: | CAAaqYe9XqLmDpZ3gOShoUcYNXQ6jw1yWABB1oZj5XhFib_22nA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 20, 2022 at 3:31 PM Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>
> On 1/20/22 12:25, Bossart, Nathan wrote:
> > 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.
> >
>
> I still don't understand the confusion. When you add a new column with a
> non-null non-volatile default, none of the existing rows has any storage
> for the new column, so there is nothing to scan and nothing to verify on
> such rows. Only the catalog is changed. This is true whether or not the
> new column is constrained by NOT NULL. I don't understand what people
> think might have had to be verified by scanning the table.
>
> If what's happening is not clear from the docs then by all means let's
> make it clear. But in general I don't think we should talk about what we
> used to do.
This path isn't about talking about what we used to do (though that's
already in the docs); it is about trying to make it clear.
But actually "When you add a new column with a non-null non-volatile
default...there is nothing to scan" doesn't always hold as I showed
with the check constraint above. Other than that I think that phrasing
is actually almost close to the kind of clarity I'd like to see in the
docs.
As noted earlier I expect to be posting an updated patch soon.
Thanks,
James Coleman
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2022-01-20 21:02:22 | Re: support for MERGE |
Previous Message | Bossart, Nathan | 2022-01-20 20:41:16 | Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work |