Re: [HACKERS] Fast ALTER TABLE ... ADD COLUMN ... DEFAULT xxx?

2009-05-28 Thread Dmitry Koterov
Dmitry Koterov dmi...@koterov.ru writes: No, I meant that in case of the row (1, NULL, NULL, 2, 3, NULL): - the corresponding NULL bitmap is (100110...) - the corresponding tuple is (1, 2, 3) - t_natts=3 (if I am not wrong here) You are wrong --- t_natts would be six here. In general

Re: [HACKERS] Fast ALTER TABLE ... ADD COLUMN ... DEFAULT xxx?

2009-05-24 Thread Tom Lane
Dmitry Koterov dmi...@koterov.ru writes: No, I meant that in case of the row (1, NULL, NULL, 2, 3, NULL): - the corresponding NULL bitmap is (100110...) - the corresponding tuple is (1, 2, 3) - t_natts=3 (if I am not wrong here) You are wrong --- t_natts would be six here. In general the

Re: [HACKERS] Fast ALTER TABLE ... ADD COLUMN ... DEFAULT xxx?

2009-05-22 Thread Sam Mason
On Thu, May 21, 2009 at 12:26:08PM -0400, Tom Lane wrote: I'd envision it as an extra column in pg_attribute, and it would work for any column(s). There's nothing to be gained by restricting it. Yes, when I said first I meant the only thing that needs to be stored is the first default value

Re: [HACKERS] Fast ALTER TABLE ... ADD COLUMN ... DEFAULT xxx?

2009-05-22 Thread Dmitry Koterov
On Thu, May 21, 2009 at 6:45 PM, Tom Lane t...@sss.pgh.pa.us wrote: Sam Mason s...@samason.me.uk writes: On Thu, May 21, 2009 at 12:06:29PM +0400, Dmitry Koterov wrote: ALTER TABLE ... ADD COLUMN ... NULL; (nullable without a default value). This is because of NULL bitmap in tuples.

[HACKERS] Fast ALTER TABLE ... ADD COLUMN ... DEFAULT xxx?

2009-05-21 Thread Dmitry Koterov
Hello. PostgreSQL is very fast when we perform (even on a huge table) ALTER TABLE ... ADD COLUMN ... NULL; (nullable without a default value). This is because of NULL bitmap in tuples. And it's greatest feature for a developer! But another very common-case query like ALTER TABLE ... ADD

Re: [HACKERS] Fast ALTER TABLE ... ADD COLUMN ... DEFAULT xxx?

2009-05-21 Thread Peter Eisentraut
On Thursday 21 May 2009 11:06:29 Dmitry Koterov wrote: 1. Store the DEFAULT flag directly in NULL BITMAP (add a bit to NULL bitmap not only for NULLable fields, but also for NOT NULL DEFAULT ... fields). 2. Add another bitmap for each tuple (DEFAULT bitmap). Bit value 0 means that there is a

Re: [HACKERS] Fast ALTER TABLE ... ADD COLUMN ... DEFAULT xxx?

2009-05-21 Thread Sam Mason
On Thu, May 21, 2009 at 12:06:29PM +0400, Dmitry Koterov wrote: ALTER TABLE ... ADD COLUMN ... NULL; (nullable without a default value). This is because of NULL bitmap in tuples. And it's greatest feature for a developer! I don't think this is because of the NULL bitmap. PG just never needs

Re: [HACKERS] Fast ALTER TABLE ... ADD COLUMN ... DEFAULT xxx?

2009-05-21 Thread Robert Haas
(In most cases NOT NULL DEFAULT xxx fields are BOOLEAN, flags: it is not handy to have 3-way flags.) This is certainly not true for me. I have both nullable booleans and not-nullable, defaulted columns of other types. So, are there plans to optimize such kind of queries? This could be done

Re: [HACKERS] Fast ALTER TABLE ... ADD COLUMN ... DEFAULT xxx?

2009-05-21 Thread Tom Lane
Sam Mason s...@samason.me.uk writes: On Thu, May 21, 2009 at 12:06:29PM +0400, Dmitry Koterov wrote: ALTER TABLE ... ADD COLUMN ... NULL; (nullable without a default value). This is because of NULL bitmap in tuples. And it's greatest feature for a developer! I don't think this is because

Re: [HACKERS] Fast ALTER TABLE ... ADD COLUMN ... DEFAULT xxx?

2009-05-21 Thread Robert Haas
On Thu, May 21, 2009 at 10:45 AM, Tom Lane t...@sss.pgh.pa.us wrote: Sam Mason s...@samason.me.uk writes: On Thu, May 21, 2009 at 12:06:29PM +0400, Dmitry Koterov wrote: ALTER TABLE ... ADD COLUMN ... NULL; (nullable without a default value). This is because of NULL bitmap in tuples. And

Re: [HACKERS] Fast ALTER TABLE ... ADD COLUMN ... DEFAULT xxx?

2009-05-21 Thread Greg Stark
On Thu, May 21, 2009 at 3:45 PM, Tom Lane t...@sss.pgh.pa.us wrote: All that needs to be tracked is the first default value (this is currently assumed to be NULL). You're being a bit vague, but in any case I don't think it can work for non-constant defaults (consider DEFAULT NOW()).  And

Re: [HACKERS] Fast ALTER TABLE ... ADD COLUMN ... DEFAULT xxx?

2009-05-21 Thread Tom Lane
Greg Stark st...@enterprisedb.com writes: Schemes like this have been discussed before but I don't think we considered applying the limitation that only the first default value would be covered. We always wanted to be able to handle new defaults or making a non-null column nullable later.

Re: [HACKERS] Fast ALTER TABLE ... ADD COLUMN ... DEFAULT xxx?

2009-05-21 Thread Robert Haas
On Thu, May 21, 2009 at 11:13 AM, Greg Stark st...@enterprisedb.com wrote: On Thu, May 21, 2009 at 3:45 PM, Tom Lane t...@sss.pgh.pa.us wrote: All that needs to be tracked is the first default value (this is currently assumed to be NULL). You're being a bit vague, but in any case I don't

Re: [HACKERS] Fast ALTER TABLE ... ADD COLUMN ... DEFAULT xxx?

2009-05-21 Thread Greg Stark
On Thu, May 21, 2009 at 4:22 PM, Tom Lane t...@sss.pgh.pa.us wrote: Greg Stark st...@enterprisedb.com writes: Schemes like this have been discussed before but I don't think we considered applying the limitation that only the first default value would be covered. We always wanted to be able to

Re: [HACKERS] Fast ALTER TABLE ... ADD COLUMN ... DEFAULT xxx?

2009-05-21 Thread Tom Lane
Greg Stark st...@enterprisedb.com writes: On Thu, May 21, 2009 at 4:22 PM, Tom Lane t...@sss.pgh.pa.us wrote: Yeah ... I don't see exactly what it would buy to restrict it to just the first such value. Well it wouldn't buy you steady-state space savings or performance improvements. What

Re: [HACKERS] Fast ALTER TABLE ... ADD COLUMN ... DEFAULT xxx?

2009-05-21 Thread Greg Stark
-- Greg On 21 May 2009, at 12:26, Tom Lane t...@sss.pgh.pa.us wrote: Greg Stark st...@enterprisedb.com writes: On Thu, May 21, 2009 at 4:22 PM, Tom Lane t...@sss.pgh.pa.us wrote: Yeah ... I don't see exactly what it would buy to restrict it to just the first such value. Well it