On Sun, Mar 27, 2022 at 11:12 PM David G. Johnston
wrote:
>
> On Sun, Mar 27, 2022 at 11:17 AM James Coleman wrote:
>>
>> Hmm, I didn't realize that was project policy,
>
>
> Guideline/Rule of Thumb is probably a better concept.
Ah, OK, thanks.
>>
>> but I'm a bit
>> surprised given that the s
On Mon, Mar 28, 2022 at 9:54 AM James Coleman wrote:
> No, I've appreciated constructive feedback from both Tom and David on
> this thread. Your original email was so incredibly strongly worded
> (and contained no constructive recommendations about a better path
> forward, unlike Tom's and David's
On Mon, Mar 28, 2022 at 9:30 AM Robert Haas wrote:
>
> On Sun, Mar 27, 2022 at 1:00 PM James Coleman wrote:
> > So "undocumented concept" is just not accurate, and so I don't see it
> > as a valid reason to reject the patch.
>
> I mean, I think it's pretty accurate. The fact that you can point to
On Sun, Mar 27, 2022 at 1:00 PM James Coleman wrote:
> So "undocumented concept" is just not accurate, and so I don't see it
> as a valid reason to reject the patch.
I mean, I think it's pretty accurate. The fact that you can point to a
few uses of the terms "table rewrite" and "table scan" in th
On Sun, Mar 27, 2022 at 11:17 AM James Coleman wrote:
> Hmm, I didn't realize that was project policy,
Guideline/Rule of Thumb is probably a better concept.
> but I'm a bit
> surprised given that the sentence which 0001 replaces seems like a
> direct violation of that also: "In neither case
On Sun, Mar 27, 2022 at 1:46 PM David G. Johnston
wrote:
>
> On Sun, Mar 27, 2022 at 10:00 AM James Coleman wrote:
>>
>> As shown above, table scans (and specifically table scans used to
>> validate constraints, which is what this patch is about) are clearly
>> documented (more than once!) in the
On Sun, Mar 27, 2022 at 10:00 AM James Coleman wrote:
> As shown above, table scans (and specifically table scans used to
> validate constraints, which is what this patch is about) are clearly
> documented (more than once!) in the ALTER TABLE documentation. In fact
> it's documented specifically
On Sun, Mar 27, 2022 at 11:43 AM Robert Haas wrote:
>
> On Sat, Mar 26, 2022 at 6:25 PM James Coleman wrote:
> > I simply do not accept the claim that this is not a reasonable concern
> > to have nor that this isn't worth documenting.
>
> I don't think I said that the concern wasn't reasonable, b
On Sat, Mar 26, 2022 at 6:25 PM James Coleman wrote:
> I simply do not accept the claim that this is not a reasonable concern
> to have nor that this isn't worth documenting.
I don't think I said that the concern wasn't reasonable, but I don't
think the fact that one person or organization had a
On Sat, Mar 26, 2022 at 4:36 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > Or, we can leave it where things are and make sure the reader understands
> > there are two paths to having a NOT NULL constraint on the newly added
> > column. Something like:
>
> > "If you plan on having a NOT N
"David G. Johnston" writes:
> Or, we can leave it where things are and make sure the reader understands
> there are two paths to having a NOT NULL constraint on the newly added
> column. Something like:
> "If you plan on having a NOT NULL constraint on the newly added column you
> should add it
On Sat, Mar 26, 2022 at 4:14 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
>
> I would suggest rewriting 0001 to target ALTER COLUMN instead of in the
> generic notes section (in the paragraph beginning "Adding a column with a
> volatile DEFAULT") for the desired clarification.
>
>
Or,
On Sat, Mar 26, 2022 at 3:25 PM James Coleman wrote:
> On Fri, Mar 25, 2022 at 4:40 PM Robert Haas wrote:
> >
> > On Tue, Jan 25, 2022 at 8:49 AM James Coleman wrote:
> > > Here's a version that looks like that. I'm not convinced it's an
> > > improvement over the previous version: again, I exp
On Fri, Mar 25, 2022 at 5:00 PM Tom Lane wrote:
>
> Robert Haas writes:
> > I vote for rejecting both of these patches.
>
> I see what James is on about here, but I agree that these specific changes
> don't help much. What would actually be desirable IMO is a separate
> section somewhere explain
On Fri, Mar 25, 2022 at 4:40 PM Robert Haas wrote:
>
> On Tue, Jan 25, 2022 at 8:49 AM James Coleman wrote:
> > Here's a version that looks like that. I'm not convinced it's an
> > improvement over the previous version: again, I expect more advanced
> > users to already understand this concept, a
On Fri, Mar 25, 2022 at 5:00 PM Tom Lane wrote:
> I see what James is on about here, but I agree that these specific changes
> don't help much. What would actually be desirable IMO is a separate
> section somewhere explaining the performance characteristics of ALTER
> TABLE.
Sure. If someone wan
On Fri, Mar 25, 2022 at 1:40 PM Robert Haas wrote:
> On Tue, Jan 25, 2022 at 8:49 AM James Coleman wrote:
> > Here's a version that looks like that. I'm not convinced it's an
> > improvement over the previous version: again, I expect more advanced
> > users to already understand this concept, an
Robert Haas writes:
> I vote for rejecting both of these patches.
I see what James is on about here, but I agree that these specific changes
don't help much. What would actually be desirable IMO is a separate
section somewhere explaining the performance characteristics of ALTER
TABLE. (We've al
On Tue, Jan 25, 2022 at 8:49 AM James Coleman wrote:
> Here's a version that looks like that. I'm not convinced it's an
> improvement over the previous version: again, I expect more advanced
> users to already understand this concept, and I think moving it to the
> ALTER TABLE page could very well
On Sat, Jan 22, 2022 at 10:28 AM David G. Johnston
wrote:
>
>
>
> On Saturday, January 22, 2022, James Coleman wrote:
>>
>> On Sat, Jan 22, 2022 at 12:35 AM David G. Johnston
>> wrote:
>> >
>> > On Fri, Jan 21, 2022 at 5:14 PM James Coleman wrote:
>> >>
>> >>
>> >> > Really? That's horrid, bec
On Saturday, January 22, 2022, James Coleman wrote:
> On Sat, Jan 22, 2022 at 12:35 AM David G. Johnston
> wrote:
> >
> > On Fri, Jan 21, 2022 at 5:14 PM James Coleman wrote:
> >>
> >>
> >> > Really? That's horrid, because that's directly useful advice.
> >>
> >> Remedied, but rewritten a bit
On Sat, Jan 22, 2022 at 12:35 AM David G. Johnston
wrote:
>
> On Fri, Jan 21, 2022 at 5:14 PM James Coleman wrote:
>>
>>
>> > Really? That's horrid, because that's directly useful advice.
>>
>> Remedied, but rewritten a bit to better fit with the new style/goal of
>> that tip).
>>
>> Version 3 i
On Fri, Jan 21, 2022 at 5:14 PM James Coleman wrote:
>
> > Really? That's horrid, because that's directly useful advice.
>
> Remedied, but rewritten a bit to better fit with the new style/goal of
> that tip).
>
> Version 3 is attached.
>
>
Coming back to this after a respite I think the tip need
On Fri, Jan 21, 2022 at 5:38 PM Tom Lane wrote:
>
> "David G. Johnston" writes:
> > You've removed the "constraint verification scan" portion of this.
>
> Indeed, because that's got nothing to do with adding a new column
> (per se; adding a constraint along with the column is a different
> can of
On Fri, Jan 21, 2022 at 4:08 PM Andrew Dunstan wrote:
>
>
> On 1/21/22 13:55, James Coleman wrote:
> > On Thu, Jan 20, 2022 at 3:43 PM James Coleman wrote:
> >> As noted earlier I expect to be posting an updated patch soon.
> > Here's the updated series. In 0001 I've moved the documentation tweak
"David G. Johnston" writes:
> You've removed the "constraint verification scan" portion of this.
Indeed, because that's got nothing to do with adding a new column
(per se; adding a constraint along with the column is a different
can of worms).
> Re-reading this, the recommendation:
> - Howe
On Fri, Jan 21, 2022 at 2:50 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > On Fri, Jan 21, 2022 at 2:08 PM Andrew Dunstan
> wrote:
> >> I know what it's replacing refers to release 11, but let's stop doing
> >> that. How about something like this?
> >>
> >> Adding a new column can someti
"David G. Johnston" writes:
> On Fri, Jan 21, 2022 at 2:08 PM Andrew Dunstan wrote:
>> I know what it's replacing refers to release 11, but let's stop doing
>> that. How about something like this?
>>
>> Adding a new column can sometimes require rewriting the table,
>> making it a very slow opera
On Fri, Jan 21, 2022 at 2:08 PM Andrew Dunstan wrote:
> On 1/21/22 13:55, James Coleman wrote:
>
> + Before PostgreSQL 11, adding a new
> column to a
> + table required rewriting that table, making it a very slow operation.
> + More recent versions can sometimes optimize away this rew
On 1/21/22 13:55, James Coleman wrote:
> On Thu, Jan 20, 2022 at 3:43 PM James Coleman wrote:
>> As noted earlier I expect to be posting an updated patch soon.
> Here's the updated series. In 0001 I've moved the documentation tweak
> into the ALTER TABLE notes section. In 0002 I've taken David J
On Fri, Jan 21, 2022 at 11:55 AM James Coleman wrote:
> On Thu, Jan 20, 2022 at 3:43 PM James Coleman wrote:
> >
> > As noted earlier I expect to be posting an updated patch soon.
>
> Here's the updated series. In 0001 I've moved the documentation tweak
> into the ALTER TABLE notes section. In 0
On Thu, Jan 20, 2022 at 3:43 PM James Coleman wrote:
>
> As noted earlier I expect to be posting an updated patch soon.
Here's the updated series. In 0001 I've moved the documentation tweak
into the ALTER TABLE notes section. In 0002 I've taken David J's
suggestion of shortening the "Tip" on the
On Thu, Jan 20, 2022 at 3:31 PM Andrew Dunstan wrote:
>
>
> On 1/20/22 12:25, Bossart, Nathan wrote:
> > On 1/19/22, 5:15 PM, "James Coleman" 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
> >> optim
On 1/20/22 12:25, Bossart, Nathan wrote:
> On 1/19/22, 5:15 PM, "James Coleman" 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
>>
On 1/19/22, 5:15 PM, "James Coleman" 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
On Wed, Jan 19, 2022 at 9:34 PM David G. Johnston
wrote:
>
> On Wed, Jan 19, 2022 at 6:14 PM James Coleman wrote:
>>
>> I'm open to the idea of wordsmithing here, of course, but I strongly
>> disagree that this is irrelevant data.
>
>
> Ok, but wording aside, only changing a tip in the DDL - Add
On Wed, Jan 19, 2022 at 6:14 PM James Coleman wrote:
> I'm open to the idea of wordsmithing here, of course, but I strongly
> disagree that this is irrelevant data.
Ok, but wording aside, only changing a tip in the DDL - Add Table section
doesn't seem like a complete fix. The notes in alter ta
On Wed, Jan 19, 2022 at 7:51 PM David G. Johnston
wrote:
>
> On Wed, Jan 19, 2022 at 5:08 PM Bossart, Nathan wrote:
>>
>> On 9/24/21, 7:30 AM, "James Coleman" wrote:
>> > When PG11 added the ability for ALTER TABLE ADD COLUMN to set a constant
>> > default value without rewriting the table the d
On Wed, Jan 19, 2022 at 5:08 PM Bossart, Nathan wrote:
> On 9/24/21, 7:30 AM, "James Coleman" wrote:
> > When PG11 added the ability for ALTER TABLE ADD COLUMN to set a constant
> > default value without rewriting the table the doc changes did not note
> > how the new feature interplayed with AD
On 9/24/21, 7:30 AM, "James Coleman" wrote:
> When PG11 added the ability for ALTER TABLE ADD COLUMN to set a constant
> default value without rewriting the table the doc changes did not note
> how the new feature interplayed with ADD COLUMN DEFAULT NOT NULL.
> Previously such a new column require
When PG11 added the ability for ALTER TABLE ADD COLUMN to set a constant
default value without rewriting the table the doc changes did not note
how the new feature interplayed with ADD COLUMN DEFAULT NOT NULL.
Previously such a new column required a verification table scan to
ensure no values were
41 matches
Mail list logo
