From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | dmitry(at)koterov(dot)ru |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Fast ALTER TABLE ... ADD COLUMN ... DEFAULT xxx? |
Date: | 2009-05-21 11:44:10 |
Message-ID: | 603c8f070905210444w4f44a270t53131f0e5a173825@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> (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 by
> many ways:
>
> 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 real value in a cell, 1 - that the value is default.
Both of these options would expand storage usage by a not-inconsiderable amount.
> 3. The same as (1), but always force default value to be 0 (or false or any
> other values with meaning "zero") and optimize only these cases.
I'm not sure there's any way to know this for an arbitrary data type.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-05-21 11:47:15 | Re: pull raw text of a message by message-id |
Previous Message | Tom Lane | 2009-05-21 11:29:51 | Re: Compiler warning |